DEV Community: Aditi Chaudhry

How to be Secure in the Cloud

Aditi Chaudhry — Fri, 21 Dec 2018 04:26:43 +0000

This article was first published on Medium. You can take a look at it here.

Introduction
Cloud computing has been a popular buzzword in recent years, leading some to be skeptical of its benefits. There are considerable benefits to cloud computing but most are focused on cost effectiveness and speed. Rarely do people mention how security is a benefit of moving to the cloud. The reality is that the cloud can be as secure or insecure as you make it. However, if architected properly, it is possible to have a highly resilient, scalable, secure and compliant application in the cloud.

The first benefit of moving to the cloud is that the responsibility for securing the cloud environment is shared between the customer and the cloud vendor. In an on-premise environment, the customer handles all of the security (Figure 1). In a cloud environment, the customer is only responsible for security at the operating system and above (the light blue shaded sections in Figure 2). Moving to the cloud lets the customers focus their energy on building a robust and secure application.

Figure 1:

Figure 2:

Scalability & Resiliency
Hosting an application in the cloud enables you to take advantage of on-demand scalability. The lack of scalability in an application presents a customer experience issue as well as a security threat. As an application increases in popularity, it is harder to predict what time of day customers will be accessing the site. One server cannot handle millions of requests, but having hundreds of servers lay idle during low demands parts of the day is not an ideal solution either. Instead of buying more hardware and software resources as the application grows, you can provision resources on-demand and only pay for what you need. This saves money as you only pay for what you use.

Let’s imagine a situation where you have an e-commerce site and one of your items is suddenly very in demand. While the internet loves your product, the operations team, sees a huge spike in network traffic and suddenly the server is at capacity. Orders are not being processed, downloads are incredibly slow and customers are not happy. In a cloud environment, we can utilize autoscaling and elastic load balancing to ensure that this situation does not become reality. When the load balancer experiences too much load, it can trigger an autoscaling policy to spin up new servers. When the demand diminishes, we can scale our servers back down ensuring that we are not paying for unused resources. This way all orders are completed and download times are not affected, yielding happy customers.

Scaling is not only a cost-effective method, it also makes the application resilient. If you only have one physical server and that server ever experiences some type of hardware failure, it will take time to replace the server and have the application back up and running. In the cloud, if there’s a problem with one server, it can be easily terminated and a new one can be created in less than 5 minutes. It can even be an automated process making your life easier.

Similarly, in the event that your application suffers against a DDoS attack, there is little hope in thwarting the attempt. In a cloud environment, however, we can scale up and absorb the load of a DDoS attack. The key strategy behind a DDoS attack is to bring infrastructure to a breaking point. The strategy assumes that you cannot scale to meet the attack, its success depends on this assumption. Thus, the easiest way to defeat this strategy is to design the infrastructure to scale horizontally and vertically when needed. There are four benefits of scaling that we can take advantage of in mitigating a DDoS attack:

The attack is spread over a larger area.
The attackers have to counter-attack to the new scale, taking up more of their resources.
Scaling buys us time to analyze the attack and respond with appropriate countermeasures.
Scaling provides us with additional levels of redundancy.

Scaling on-demand in the cloud provides resiliency and a means to protect an application from increased network traffic, hardware failures and DDoS attacks in a cost-effective manner. Next, we will discuss how a cloud environment can enable better identity and access management processes.

Identity and Access Management
The purpose of IAM is to provision, manage and de-provision identities that have access to your cloud environment’s infrastructure. With IAM, you can centrally manage users, security credentials, access keys and permissions policies that control which services and resources users can access. This is important because without an account permission strategy, anyone would have the ability to run privileged commands. Situations both unintentional and intentional could occur where someone could wreck havoc on the system using privileged commands. Setting up Identity and Access Management (IAM) in a cloud environment can help ensure that this does not happen.

The goal is to never have to login as the root user. There are four components to IAM which enable secure and least privilege access to the infrastructure and application.

Central User Repository — This stores and delivers identity information to other services.
Authentication — This establishes an identity by asking who you are and verifying the identity claim with one or more authentication factors.
Authorization — This evaluates what you have permission to access whatever it is you are trying to access after authentication.
User Management — This manages the user lifecycle (onboarding, offboarding, role changes, identity/password changes).

Authentication is made simple in the cloud with the use of federated identity management (FIM). When using FIM, the application doesn’t need to focus on identification and authentication, just authorization. There are different federation standards that can be used for authentication including Single Sign On (SSO), SAML, Oauth, OpenID Connect and WS-Federation. These standards can be used to make sure that users, developers and admins only have the access they need, enforcing the principle of least privilege.

IAM helps us regulate who has access to the data, but we also need to be mindful of how we are protecting data in the cloud.

Data Protection
Using the same example of an e-commerce application, in the event of a hardware failure that causes data loss, you would lose more than just application code. Chances are, your application could contain sensitive customer information such as personally identifiable information (PII) and credit card information, which would also be lost.

Creating backups via snapshots is easy in the cloud. We can create snapshots for the database and storage volumes and restore data from these snapshots if necessary. Many cloud providers also have storage options, including archival storage, with high durability that can be part of our backup strategy.

We also want to make sure that we are securing any sensitive information that is either stored or processed through the application. Thus, we should encrypt data in transit and at rest. To encrypt data at rest, we should encrypt the whole disk or volume where the data is stored. While data is in transit, we should use TLS or VPNs to encrypt the data.

We also want to protect the application from common web exploits, such as SQL Injection and cross-site scripting, that could compromise security or affect availability. We want to filter out known bad IP addresses and monitor HTTP and HTTPs requests. We can use a web application firewall (WAF) to do this. Typically, firewalls are built in to the cloud environment with default deny which grants our application and data an extra layer of protection.

Protecting our data is not enough, we need to also ensure that we are compliant with any laws and regulations.

Compliance
Assuming our sample application processes credit card information, we need to make sure that we are PCI-DSS compliant. We can choose a cloud provider who is PCI-DSS compliant such as AWS or one that ensures that the way we store, process or transmit cardholder data in compliance with the standards. We should also make sure that we are in compliance with any data retention policies that exist. Lifecycle rules can be used in certain storage solutions to meet any data retention policies.

If the application ever goes through an audit, you won’t have to spend hours preparing for the audit as asset inventory and auditing tools are built-in cloud services. Since every call made in a cloud environment is an API call, there is extensive API call logging. Logs may contain console/API logins, high rate of API activity, new kinds of API activity and new IP addresses accessing the database. These logs can be useful in the event of a data breach or cyber-attack as well.

Setting up secure infrastructure, protecting our data and ensuring compliance will only be useful if the actual application code is secure. With the shift to the cloud, developers can start to embrace DevSecOps and its principles related to secure coding practices.

Secure Coding Practices
Following DevSecOps principles can lead to a robust patching strategy as well as secure code. One DevSecOps principle states “Automate security updates.” This is an important principle as it pertains to using automated tools for patching the OS, core services and the application itself. Developers can use tools such as Puppet and Chef to enable continuous patching in the cloud environment.

Another DevSecOps principle states, “Integrate and automate security scanning from the start.” To establish secure coding practices, we can embrace code analysis through both automated tools and manual code review. We should review the code every time there is a meaningful change in the code base. Additionally, we should conduct static and dynamic penetration tests against our code to find any vulnerabilities and then mitigate them before releasing the code into production.

Conclusion
As you can see, many characteristics of the cloud lend themselves nicely to security. We can use autoscaling to provide scalability and resiliency, IAM to regulate user and resource access, cloud services for data protection and compliance, and DevSecOps for secure coding practices. Thus it is possible to have secure applications in a cloud environment.

This is my twelfth post in my "What is" tech blog series. I'll be writing more every week here and on my blog!

What is DevSecOps?

Aditi Chaudhry — Thu, 13 Sep 2018 01:22:45 +0000

This article was first published on Medium. You can take a look at it here.

With everyone moving to the cloud, there’s been so much hype over DevOps and how it can make processes faster, easier, and more efficient. As a developer, I love when things are made easier for me. As someone in security though, it scares me that there is no emphasis on moving to the cloud securely. Enter DevSecOps.

DevSecOps is about introducing security earlier in the software development life cycle (SDLC). The goal is to develop more secure applications by making everyone involved in the SDLC responsible for security. I love this. Having business, tech and security work together to produce secure products seems like a dream come true. Maybe too good to be true? Let’s investigate more and see if DevSecOps can be the silver bullet we all need in building secure products.

First, let’s talk about why we need DevSecOps. Years ago, software products followed the waterfall methodology, a linear sequential approach for developing a product that concluded with a “big-bang” release.

With the shift to cloud computing and dynamic provisioning of resources, developers have gained numerous benefits around speed, scale and cost of application development. These benefits lend themselves so nicely to the adoption of the DevOps movement. DevOps strongly advocates for automation and monitoring at all steps of the SDLC. The goal is for shorter development cycles, increased deployment frequency and more dependable releases, all aligned with business objectives. Like I said before, as a developer, I love this. But stable infrastructure and applications does not equal secure infrastructure and applications. And that worries me. In the waterfall lifecycle, security checks were put at the end before the product was released. Security was seen as a roadblock, the last gate-check, on the way to a production release. Many things have changed in regards to how applications are developed, but not how security is viewed.

These days, most teams use the agile methodology for software development. In an agile environment, the focus is on rapid delivery. By using iterative planning and feedback results, teams can continuously align product deliverables to business needs. The adaptability to changing requirements is great for delivering a meaningful product, but if you’re releasing a new version of your product every week, when do you test for security vulnerabilities? Unfortunately, traditional security processes have not kept pace in agile/DevOps environments rendering security to become a major roadblock in software development where it is usually bypassed. If it’s not bypassed, the development team rarely has enough time to address all the issues before the product goes live which means that an insecure application lives somewhere on the internet. The ironic part is that ignoring security to avoid the risk of missing a deadline actually puts more risk into the application. Security defects in the SDLC can lead to serious vulnerabilities like a breach caused by bad code. This is why we need DevSecOps.

In DevSecOps the two seemingly opposing goals, “speed of delivery” and “secure code”, are merged into one streamlined/automated process. The intent of DevSecOps is to build on the mindset that “everyone is responsible for security.” It is about pushing security left and automating core security tasks. Remember the song Irreplaceable by Beyonce? Throwback, I know, but Beyonce had the right idea when she sang “to the left, to the left.”

We want to push security to the left of the SDLC to ensure that application security starts as one codes. By shifting left, teams can quickly discover and analyze vulnerabilities and then adapt their code to mitigate against those vulnerabilities.

DevSecOps allows developers to focus on writing high quality and secure code, enabling teams to release titanium applications. The benefits are simple:

security from the start minimizes the chance of vulnerabilities
having automated security tools running in pipelines is that it lets security team members focus on the high-hanging fruit
better collaboration and communication between dev and security teams
improved operational efficiencies across security and the enterprise

However, there are challenges associated with DevSecOps. Even with security baked into a pipeline, there are still ways to circumvent security checkpoints. Lets take an example where a vulnerability scanner is being used to block a build/deployment if a certain vulnerability is found. As a developer, you know what that vulnerability is and you know your code has it, but you really need to do this release. So you find a way to hide pieces of the code that you know will fail a security scan, resulting in a successful build. Another common situation is when teams decide to break their build if there’s a presence of one or more findings of a certain severity. For example, a team may say that they do not want to break their build unless the finding is high or critical. While this certainly helps identify and address high priority issues immediately, the consequence is that medium and low findings make it to production builds.

Now that we’ve gone over the pros and cons of DevSecOps, how does one actually implement it? The traditional DevOps tools such as Jenkins and Git are a must have to build the foundation of your DevOps pipeline. There are many security tools in the marketplace ranging from open-source to proprietary solutions. Many of these can be integrated into your existing pipelines. Below is a list I’ve compiled from experience and the internet:

Checkmarx: A SAST (Static Application Security Testing) Tool that analyzes an application’s code for flaws which are indicative of security vulnerabilities.
WhiteSource: An open source vulnerability scanner, which runs automatically and continuously in the background, tracking the security, licensing, and quality of open source components and matching them against WhiteSource’s comprehensive database of open source repositories.
Zaproxy: The OWASP Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.

So is DevSecOps the magical cure to all of our problems. Maybe not all of our problems, but to me and many others, it’s irreplaceable and this is one hype train I’m ready to board and take all the way.

This is my eleventh post in my "What is" tech blog series. I'll be writing more every week here and on my blog!

What is a Mentor?

Aditi Chaudhry — Tue, 06 Feb 2018 02:10:41 +0000

This article was first published on Medium. You can take a look at it here.

Last October, I had the opportunity to work with the Girl Scouts of the Nation’s Capital to develop a robotics activity for Cadette’s to earn their STEM badge. The activities were designed to teach the middle school girls how robotics relates to STEM and to excite them about the possibilities in the field. We built catapults, designed rafts to hold 25 pennies and learned about algorithms and encryption. As I looked around the classroom, I had one thought running through my mind: ten years ago, I was the only girl in my robotics class and now I’m surrounded by almost 100 middle school girls hyped about robotics. This was amazing!

At the end of the day, one parent thanked me for being a role model and a mentor. I had never considered myself to be a mentor. My mom is my mentor, my teachers and professors are mentors, but not me…right? Well apparently, that’s false. So I asked myself, what is a mentor?

I believe a mentor is someone you can look up to, someone who can show you the ropes and that your potential is limitless, someone to help you believe. The mentors I have in my life push me to be better: a better technologist, a better teammate, a better person. They do so by being honest with me, whether I did something good or if I made a mistake. One of my mentors tells me, “you never lose, you only win or you learn.” Sometimes its hard to hear that you messed up, but having an open conversation about what happened is how you learn and how you ensure that you never make the same mistake twice.

Two other qualities I recognize in a good mentor:

A mentor will share his/her experiences with you to contribute to your knowledge base.
A mentor will use his/her network to help you succeed to achieve your goals.

Well that’s great, we can all agree that everyone should have a mentor, but how does one go about actually getting a mentor. What worked for me was to find someone I admired, not for her position at my company, but for her strengths and skills so that when I say, “I want to be like her,” I mean I want to be a confident public speaker and a respected technologist. I then started attending networking events where I found her and introduced myself and started to have casual conversations. It is important to realize that mentoring is like any other relationship and that it will grow over time based on respect and trust. Mentoring is organic, so forcing it will kill the potential relationship. I never formally asked my mentor to be my mentor. However, I did ask if I could set up a monthly meeting with her so we could stay in touch. Take the initiative, you can’t just wait for someone to find you and mentor you.

It’s also important to note that mentorship is a two-way street. A mentor will give advice but they are also actively listening to your opinions to evolve their thinking and consider different points of view.

Having a mentor is great but being a mentor is equally rewarding. Thinking back to my experience in my robotics class, if I had been discouraged by being the only girl, my life would be very different today. I was lucky to have a supportive teacher who encouraged my passion for robotics and technology, it helped shape who I am today. And I think that’s the true meaning of being a mentor, providing someone with a positive experience so that they feel confident to succeed in whatever they choose.

This is my ninth post in my "What is" tech blog series. I'll be writing more every week here and on my blog!

What is Imposter Syndrome?

Aditi Chaudhry — Tue, 06 Feb 2018 01:52:30 +0000

This article was first published on Medium. You can take a look at it here.

Wikipedia defines imposter syndrome as “a concept describing individuals who are marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a ‘fraud.’” I like to describe it as the opposite of the Michael Scott syndrome (Michael Scott from the TV show The Office). Michael Scott was a great character, but anyone who has seen the show can attest that his confidence was not justified by his competence.

To me, imposter syndrome is when you are competent, but you are not confident in your competency (try saying that 5 times fast).

The graph below shows confidence and competence on either axis. Ideally, as our competence grows, so does our confidence. People who experience Imposter Syndrome fall to the left of the dotted line.

When you’re going through imposter syndrome, you feel like a fake. You don’t feel good enough and no matter how hard you try, you feel like nothing you do will ever be good enough. You’re terrified that one day you’ll be exposed as the fraud you believe yourself to be (note: I didn’t say the fraud you are). It’s quite debilitating, going through these thoughts and emotions. So what should you do if you feel yourself overcome with such thoughts?

Step 1: Acknowledge the thoughts. I know this sounds cliché, but if you don’t recognize these disruptive thoughts, you can’t overcome them.

Step 2: Stop belittling yourself and your achievements. I’ve found one of the most common symptoms to be negative self-talk. People will under-sell their achievements or say “they just got lucky,” when in fact their success could be attributed to merit and hard work. So reframe your thoughts and what you say in a more positive light. This is different than bragging or being arrogant or not being humble about your accomplishments. You are simply telling the truth about what you have done, it’s not your fault that it sounds so good.

I used to talk about writing as “just something that I do, it’s not a big deal, people probably don’t even read what I’m writing.” When in reality people were reading my articles and commenting telling me how they learned something from what I wrote. Now, I tell people that I write about technology and reach over a thousand people on Medium and that I’m happy and proud of my work. People’s perception of you is based on your perception of yourself. If you don’t think you’re great or worth it, other people will have a hard time seeing it as well.

Step 3: Have a group of friends, family, mentors who will help empower you. Surround yourself with people who want to see you rise to the sky, not ones who would drag you through the mud. Whenever you’re having a moment of self-doubt, go talk to someone from your trusted circle. They will remind you of your potential and brilliance.

Step 4: Make an empowering playlist! I have a “confidence boosting” playlist on Spotify that I listen to whenever I need a something to help hype me up and get me to say “yes, I can do it!”

Hopefully these steps can help you overcome your feelings of imposter syndrome and help you achieve your full potential!

This is my tenth post in my "What is" tech blog series. I'll be writing more every week here and on my blog!

What is Serverless?

Aditi Chaudhry — Tue, 12 Dec 2017 02:21:21 +0000

This article was first published on Medium. You can take a look at it here.

I’ve had someone tell me before that serverless is great because the code isn’t running on a server. Well obviously the code is not running in thin air, so where is it running in a serverless architecture? What is serverless and why is there so much hype around it? Is the hype even worth it?

The term serverless is misleading because servers still exist, but developers do not need to worry about managing the server. Going serverless means that developers focus on the application at the task level instead of at the server level. Now, they don’t need to worry about managing and operating servers or runtimes in the cloud or on-prem.

Serverless can also be described as Functions as a Service (FaaS). FaaS products execute functions (code) that are run on demand in response to events. The benefit to running code on demand is in the use case where your code does not need to be running full time. When you use a serverless product you only pay for the resources your application consumes, not a pre-purchased unit. In certain scenarios this could save you money. The other benefit to having your code broken down into functions is that scaling and deploying individual functions is much easier. Let’s imagine that one specific function is computationally heavier than another; in a serverless architecture that function can be individually scaled instead of having to scale your entire application.

This sounds a little like microservices, and the concept is similar. The goal of a microservice is to break your large application into small, decoupled, independent systems that connect back together to make your application work (read more here). Functions go one step further and are smaller than microservices, think one microservice can contain multiple functions. The difference comes in use cases. There are some things that are not suitable for functions and vice versa. Ultimately, functions/serverless and microservices both have their place in development but each have their strengths and weaknesses.

So what are the strengths or benefits of serverless? We talked about scalability and cost but is there anything else? As a developer, serverless is nice because you don’t need to provision or maintain any servers. In the situation where you just want to write code that responds to events but don’t need to create an entire application, serverless is awesome. Additionally, some serverless services such as AWS Lambda provide availability and fault tolerance by default, so as a developer you have two less things to worry about. Additionally, serverless can improve application resiliency. Since your code is not hosted on one specific server, you do not have a single point of failure. If the machine your code is running on fails, the serverless provider will switch your code over to a new machine and there shouldn’t be any effect on the user experience. Basically, if developers aren’t worrying about servers, they can spend that time and energy on developing scalable and reliable products.

But someone still needs to worry about the servers because our code isn’t running magically in never never land. Even from an ops perspective there is a potential for saving money. First, you won’t be running and paying for your application 24/7, only on-demand. Additionally, just like with microservices, with serverless infrastructure you can optimize your resources which could also cut down on costs.

Serverless seems great so far, but behind the hype there are some downsides. First is the complexity of designing and maintaining serverless architecture. Breaking your application into microservices introduces complexity. Breaking your microservices down further into functions takes complexity to a whole new level. There is architectural complexity of designing and building a distributed computing architecture. There is the complexity of maintaining such a system and there is also the pain of debugging a distributed system. As of now, there aren’t that many tools to help developers monitor/debug serverless environments but I’m sure there will be soon.

The second downside is performance. In a serverless architecture, you will experience higher latency as your functions respond to the triggers/requirements of the application. When your function is triggered for the first time after a while, a machine has to spin up for your function to be executed. In AWS Lambda, your instance stays up for about 10 minutes after your function’s first execution so it’s available for any subsequent calls. After those ten minutes, you will have to wait again for a new instance to spin-up. If performance is a high priority, I would stick with allocated servers (cloud or on-prem).

The third problem is vendor lock-in. Switching from one vendor to another would probably require you to update/change your code, operational tools, design and architecture. So moving your code from one solution to another would require significant energy. Currently there are several vendors on the market. Here’s a brief overview of the top 4 (in no particular order):

AWS Lambda is probably the biggest and most known serverless framework. It started with Node.js but supports Java and Python. AWS Lambda is convenient to use as it is integrated with other AWS services and the Alexa Skills Kit. A developer can use the interactive console and/or command line tools to upload and manage code.
Google Cloud Functions is an AWS Lambda competitor that runs on Google’s public cloud infrastructure. This platform supports only Node.js. One main differentiator between Google Cloud Functions and AWS Lambda is that AWS provides more services that can integrate with Lambda. Only a few services such as Google Cloud Storage are integrated with Google Cloud Functions.
IBM OpenWhisk is an open source alternative to AWS Lambda and is integrated with IBM Bluemix. OpenWhisk supports Node.js and Swift. Developers can interact with the framework through a CLI and can install OpenWhisk on a local Ubuntu machine. I think the best part of OpenWhisk is that it can be integrated with any 3rd party service that supports Webhooks.
Microsoft Azure Functions supports a variety of languages including JavaScript and Python. Microsoft provides an IDE in their portal to help developers prototype and deploy their functions.

I believe that AWS Lambda is the most mature serverless framework. AWS launched Lambda in 2014, Google and Microsoft launched their alternative solutions two years later. AWS Lambda supports advanced features like request chaining and edge processing and integrates into a wide range of AWS products.

In conclusion, is serverless worth all the hype? In certain use cases and situations, serverless can be brilliant. If your application is event-driven or used sporadically and performance is not an issue, it is a good approach for consuming cloud resources while keeping cost low. However, it is not ideal for other situations like when you have a long-running task/service. In these scenarios, serverless could end up costing you more money, negating one of its primary benefits. I think right now serverless is a little young and enterprises are still trying to figure out if it is the right solution for them. I am, however, very excited for the future of serverless computing as I believe it has great potential, especially as more tools to monitor and debug functions evolve.

This is my eighth post in my "What is" tech blog series. I'll be writing more every week here and on my blog!

If She Can See It, She Can Be It

Aditi Chaudhry — Sun, 05 Nov 2017 18:00:39 +0000

This article was first published on Medium. You can take a look at it here

As a woman in technology, it matters to me that young girls remain interested in and pursue careers in STEM. The lack of women in STEM is of international interest, but in the United States (US), it is a national issue. Currently in the US, only 25% of STEM professionals are women. Encouraging young girls to stay interested in STEM is one step forward to retaining women in the technology field.

The Leaky Tech Pipeline shows that women are dropping out of STEM at every stage of life. Research shows that boys and girls in the US start with equal interest and aptitude in STEM but by middle school, 26% of girls drop out of the field. What could cause Â¼ of girls to drop out so early?

We live in an age where children spend half their waking hours consuming media. Children are impressionable; what they see on TV shapes their perceptions of their potential and their role in society. If girls see female characters on TV being bad at math and the boys excelling, that’s what they will start to believe.

Growing up, I thought Lindsay Lohan’s character in “Mean Girls” was cool for being the one who correctly answered the winning question at the state math competition. But apparently I was the only one. I didn’t understand why her interest in math made her weird. Why was joining the math team considered social suicide?

She pretended that she didn’t understand math problems to get a boy’s attention. She started to fail math so she could talk to him. She even asked him for help, knowing that he was wrong. His steps were wrong, his answers were wrong, but she continued to pretend to be someone she was not. I was genuinely confused. Why did she need to dumb herself down to feel accepted by her peers? Why did she think boys wouldn’t like her if she was smart?

TV shows rarely have a female protagonist who is strong, independent, intelligent and beautiful. However, if the character is intelligent, she possesses certain quirks that are viewed as undesirable. Even “The Big Bang Theory,” a show about physicists, compares attractive Penny with socially-awkward, nerdy Amy forcing the viewers to think who would want to be Amy? How can we expect the next generation of girls to pursue STEM subjects when the media depicts intellectual women in a negative light?

We need young girls to stay interested in STEM to help fix the leaky pipeline and keep more women in tech. But why does this matter? Women in STEM boost productivity and profitability. Women on tech teams boost problem-solving and creativity. Teams that have at least 1 female member outperform all-male teams. And return on investment is higher for tech companies with more women in management.

So what is the solution? We need to celebrate the accomplishments of women in STEM and promote awareness of their achievements. Anita Borg and Grace Hopper laid the foundation for present day technology, But how many people know of their contributions to computer science? Katherine Johnson shattered the stereotype about women in mathematical computation with her contributions to the NASA space program. However, her contributions became common knowledge after the movie “Hidden Figures” was released.

In The Dark Knight Rises, Batman tells Rachel that “Gotham needs a hero with a face” for the city to be saved. Similarly, today’s young girls need a “hero with a face” to look up to and aspire to become. Because if she can see it, she can be it.

What is Blockchain?

Aditi Chaudhry — Thu, 07 Sep 2017 00:57:18 +0000

This article was first published on Medium. You can take a look at it here

Since I was in high-school (~2008), there has always been hype around blockchain and bitcoin. At first, I thought they were the same thing (awkward) and didn't really understand the hype over digital money. Lately, there has been even more discussion about the benefits about blockchain so I decided to find out, what is blockchain and why is it considered to be so amazing.

Blockchain is a public ledger of transactions that is composed of two parts: Peer-to-peer network, and a decentralized, distributed database. A block is a collection of data that has 4 main properties:

Time-stamped - each block has the exact time of creation
Decentralized - each block is recorded in multiple places
Open - there is no central authority
Secure by design - once the block is created, it is basically written in stone, making it extremely difficult to modify or hack

The chain connects each block together. Each block refers to the one before building up the chain.

Basically, it's just a record. A blockchain is like a ledger that a bank would use to keep track of all customer transactions. However, in a bank, the ledger is controlled by the bank and only the bank can see the transactions. In blockchain, there is no central authority. It is like a giant, global spreadsheet that runs on millions of computers and doesn't require any single person to authenticate or settle transactions.

Let's walk through a more concrete example of this concept. Let's say I want to sell my best friend Alice a bracelet. We meet up and I give her the bracelet and she gives me $5. Now she has the bracelet and can do whatever she wants with it. I don't have any more bracelets so I can't sell the bracelet to anyone else. This is an example of a simple physical transaction between the two of us. We did not need a third party to confirm that the bracelet went from me to Alice.

Let's now consider what would happen if I wanted to sell Alice a digital bracelet. How would Alice know the bracelet is mine and that I wasn't selling it to 100 people at the same time? The bracelet needs to be tracked. If I use a digital ledger to track the bracelets, I would need to put a third party in charge of the ledger so that I won't cheat my inventory or sales numbers. So I'm going to ask Bob to be my accountant. But Bob could do the same thing which defeats the purpose of hiring Bob. Also, having Bob as my accountant costs me money which means that my bracelets became more expensive. It seems like a lose-lose situation.

Then what's the happy solution? Instead of Bob being in charge of my ledger, I'll give the ledger to everyone. Now it is on everyone's computer, not just Bob's or mine and every bracelet transaction is recorded. This is great! Now no one can create 100 digital bracelets or say they have bracelets that they don't have because the ledgers on everyone else's computer won't support the inaccuracy of the ledger on the scammer's computer. The more ledgers in the system, the harder it is to cheat.

This example illustrates one of the main advantages of blockchain, that it allows us to record transactions in a trustworthy manner. Blockchain is permanent, once written, you cannot alter the information. Additionally, it is verifiable because it is in public record, not under the control of a single entity. This also means that there is no single point of failure, providing more resiliency. There are many more advantages (and disadvantages) of blockchain technology but the few outlined in this article demonstrate why this technology has amassed so much hype over the years!

This is the seventh post in my "What is" tech blog series. I'll be writing more every here and on my blog!

What is a WAF?

Aditi Chaudhry — Sat, 05 Aug 2017 16:09:48 +0000

This article was first published on Medium. You can take a look at it here

A web application firewall, aka a WAF, is an application firewall. It is deployed to protect specific web applications from common attacks such as cross site scripting and SQL injection. WAFs are different from proxies as WAFs protect servers and proxies generally protect clients.

A traditional network firewall is good at stopping illegitimate traffic and providing network-level security. A network firewall acts as a barrier between a trusted network and an untrusted network. The firewall’s policy defines what traffic is allowed onto the network, all other traffic is denied. The disadvantage of a network firewall is that it does not have the ability to detect and stop attacks that result from vulnerabilities found in web applications. These attacks are disguised as genuine requests to the application. A traditional firewall allows these requests to proceed because they appear to be normal rendering them unable to guard against these attacks. Once the request gets through, a hacker can perform a number of actions to access sensitive data stored on the application. A WAF proactively protects web applications from these threats by examining web traffic for suspicious activity.

So how does a WAF actually work?

The WAF analyzes incoming HTTP requests before they reach the server. It looks at both GET and POST based HTTP requests and applies a set of rules to determine whether the traffic is malicious or not. If the traffic is determined to be illegitimate, it is automatically filtered out. Imagine that the WAF is like a bouncer. It has a set of rules that it uses to determine which data packets to filter out. Similarly, a bouncer follows a set of rules (is the person over 21) to determine who should be allowed entry.

A WAF can be network-based, host-based or cloud-based. Network-based WAFs are usually hardware-based and have the benefit of reducing latency because they are installed as close to the application as possible. The drawback for network-based WAFs is the cost. Host-based WAFs have the ability to be fully integrated into the application code. This provides low cost and increased customization. However, they can be challenging to manage because of the dependency on local server resources. Cloud-based WAFs are easy to deploy and low cost, but as a third-party product, some aspects may be a black box.

It is important to note that WAFs are not a silver bullet for securing web applications. They will not protect against application logic flaws, session management vulnerabilities, weak passwords, insider threat, etc. WAFs are good at what they do, but they should never be relied on individually. You wouldn’t depend on just airbags in the car to keep you safe, you make sure your brakes are working and your mirrors are set to minimize any blind spots. Just like in life, in the digital world, the best defense is always a layered defense.

This is the sixth post in my "What is" tech blog series. I'll be writing more every week here and on my blog!

What is Encryption?

Aditi Chaudhry — Tue, 01 Aug 2017 01:33:37 +0000

This article was first published on Medium. You can take a look at it here

Lately, there’s been a lot of buzz about encryption. A lot of people have this misconception that encryption is complicated and only a rocket scientist can understand the concept. False, encryption is everywhere and contrary to popular thought, it isn’t very complicated. Encryption can be as simple as a secret code that two 5 year olds came up. Fundamentally, encryption is when you take some readable/understandable information and scramble it up into gibberish. The goal of encryption is to stop anyone, besides the intended recipients, from reading the message.

Encryption is not a new concept. The technique dates back millennia, to the times of Julius Caesar. In 45 BC, in ancient Rome, Julius Caesar used the “Caesar Cipher” to encode messages to his top generals. Since then, modern warfare has expanded the use of encryption. In World War II, the Germans created Enigma, a machine to encrypt their messages. The British created Colossus in response to decrypt the Nazi messages. Today, encryption is used very frequently, especially in messaging applications.

So what exactly is encryption and how does one go about implementing it. Before we walk through an example, let’s define a few terms.

Plaintextâ€Š–â€ŠThis is the text/data in raw form, this is what will encrypted
Cipherâ€Š–â€ŠThis is the algorithm, or group of steps performed on the data, that is used to encrypt the plaintext.
Ciphertextâ€Š–â€ŠThis is the encrypted text/data obtained when applying a cipher to the plaintext
Encryptionâ€Š–â€ŠThis is the process of obtaining a ciphertext from plaintext
Decryptionâ€Š–â€ŠThis is the process of obtaining a plaintext from a ciphertext (the reverse of encryption)

Let’s walk through an example with the sentence â€˜you are awesome’. This sentence is our plaintext. Our cipher will be moving each letter down one space in the alphabet, so that A becomes B, B becomes C and so on. Our ciphertext then becomes â€˜zpv bsf bxftpnf’. This encryption method is an example of the Caesar Cipher. To decrypt the message, the intended recipient must know that it was encrypted by shifting each letter down one. Then the recipient simply reverses the process to decrypt the message!

There are two types of encryption used today, symmetric and asymmetric. The difference between these methods is the way they use keys to encrypt and decrypt messages. In symmetric encryption, the sender and receiver use the same key to encrypt and decrypt the message. The Caesar Cipher (mentioned above) is an example of symmetric encryption. Caesar and his generals would both use the same agreed upon key (shifting the alphabet by one) when encrypting and decrypting the message. Symmetric key encryption is a great way to transfer information among a small group of people. However, it is not scalable. If Caesar wanted to send one general a message he didn’t want the other generals to read, he would have to have a separate encryption key for that specific general. As the number of generals who would receive different messages grows, so does the number of symmetric keys. The formula to calculate how many symmetric keys are needed for n participants is n*(n-1)/2. The number of keys needed can get out of hand very quickly for large groups.

Asymmetric key encryption solves the scalability problem by providing each user with a pair of keys, a public key and a private key. A message encrypted with one key from the pair, can only be decrypted with the other key from the pair. Let’s walk through an example with cryptography’s favorite characters, Alice and Bob. Alice and Bob each have a public and private key. Their public keys are distributed freely to any use. If Alice wants to send Bob a message, she encrypts it with Bob’s public key, which everyone knows. When Bob receives the message, he uses his private key, known only to him, to decrypt the message. This solves the scalability issue by requiring only two keys per user or 2n. The table below demonstrates the number of keys required per the number of participants for both encryption scenarios.

Number of Participants (n)	Number of Symmetric Keys	Number of Asymmetric Keys
2	1	4
4	6	8
10	45	20
100	4,950	200
1,000	499,500	2,000
10,000	4,999,500	20,000

But what if there’s a malicious attacker who is trying to intercept Alice’s message to Bob? If Eve is eavesdropping between Alice and Bob, she may be able to obtain the encrypted message, but she can only decrypt it using Bob’s private key which only Bob has. This is a fundamental principle in security called Kerckhoffs' principle. It states that the details of the algorithm used to encrypt/decrypt messages can be publicly known but not the key.

Why would we want our algorithm to be exposed to everyone? Isn’t that contradictory to being secure?

It actually isn’t; having a secret algorithm is bad practice in security. This is referred to as â€˜security through obscurity.’ Security through obscurity is bad because it implies that obscurity is the principal means of security. Obscurity is fine until it is discovered. Once found, the system is vulnerable again which is basically like having no security at all. Consider the scenario of burying $1000 under a tree. The only way your money is safe is if no one know it is there. Real security would be putting your money in a safe. There are thousands of the same safe but if someone found your safe, they would not be able to get your money because only you have the combination. The safe in this example is the algorithm, it is publicly known but the security lies within your combination, or the key.

While these are the basics of encryption, it is important to note that encryption is not entirely foolproof. A malicious attacker could still gain access to your message by simple means such as reading the message on your screen or by a more involved attack such as man-in-the-middle. There are ways to prevent such attacks but protecting data online is not an easy task. Rest assured though that the underlying mathematics of current day encryption algorithms are much more sophisticated than the examples provided in this article. While the actual algorithms are complicated, the basic fundamentals of symmetric and asymmetric encryption are less intimidating!

This is the fifth post in my "What is" tech blog series. I'll be writing more every week here and on my blog!

What is AI?

Aditi Chaudhry — Sun, 23 Jul 2017 00:10:52 +0000

This article was first published on Medium. You can take a look at it here

Hollywood has created an image that equates Artificial Intelligence (AI) with iRobot, The Terminator and Ex Machina. While these are valid examples of AI, it is not all encompassing. AI is not a new technology, it has been around since the 1950's when John McCarthy coined the term Artificial Intelligence.

So what exactly is AI? Artificial Intelligence is defined as the science of making computers execute actions that require intelligence. In the context of AI, intelligence is the ability to adapt behavior to fit new circumstances.

The goal of AI is to create a computer that can think like a human. But why are we trying to make computers more like us? Isn't a computer more complicated than my brain? False, the most complex network/system in the world is the human brain. By teaching a computer how to think like a human, we can solve hard problems and improve on existing services such as speech recognition!

You're saying a computer can learn?

Yes, a computer can learn, but it is a somewhat slow process and the computer needs a lot of training. There are multiple forms of learning, the simplest is trial-and-error. Trial-and-error is where the program will try out actions at random until it finds success. Rote learning is when the program remembers the successful action and is able to produce that action the next time it is given the same problem. Trial-and-error and rote learning are relatively easy to implement, generalization learning is a little more challenging. Generalization learning allows the program to perform better in scenarios the program has not seen before.

Cool, the computer "learned" things, now what?

As I mentioned before, the implementation of AI can help solve complex problems in a variety of fields. Three popular fields are gaming, vision systems and speech recognition. AI has been implemented in gaming where it plays a crucial role in strategic games such as chess and tic-tac-toe. Vision systems incorporate AI to help systems understand, interpret and comprehend visual input on the computer. An example of a vision system is facial recognition on a camera. Speech recognition devices, such as Amazon's Alexa, use AI to listen and comprehend human speech.

While the goal of generalized learning might be years away, the impact of AI can already be felt in the short term through Weak AI applications. According to AI philosophy, there are two major types of AI: Weak AI and Strong AI. Weak AI is focused on developing technology that can act like a human. Weak AI applications make humans feel that the machine is acting intelligently, but in reality they are not. An example of a Weak AI application is a computer playing chess. The chess application isn't actually thinking or planning, it's making moves based on what it "learned" from human input.

Strong AI on the other hand, is focused on developing technology that can think and function similar to humans, not just mimic human behavior. We are still in the process of creating Strong AI applications, but one day, these applications will actually act and think just as we do. Strong AI applications are what we see portrayed in movies such as iRobot.

AI is a very broad field and has many subdomains such as machine learning and deep learning. As computers become more powerful, the AI revolution will continue and I'm sure we will see exciting products and services emerge from the market.

This is the fourth post in my "What is" tech blog series. I'll be writing more every week here and on my blog!

What is a Microservice?

Aditi Chaudhry — Fri, 14 Jul 2017 21:08:30 +0000

This article was first published on Medium. You can take a look at it here

Microservices are becoming a very popular architecture design for application design. But every time someone tries to explain what a microservice is to me, I have the same question: what exactly is a microservice and how is it different than an API (if it even is different)?

Last week I described an API as an interface that allows software applications to communicate with each other. A microservice on the other hand, is a small component of a large application. The API is the interface to expose the functionality in the components (aka microservices). APIs are not microservices and microservices are not the implementation of an API. They are related, but not the same.

But what's the need for microservices, why aren't APIs good enough? Applications tend to grow overtime, becoming monolithic beasts. In these situations, the complexity of the application increases to the point where a single developer cannot fully understand the whole code base. Thus, bug fixes and implementing new features becomes more difficult and time consuming. What's worse is that these new changes may not even be made correctly because of the complexity of the application.

Another problem with monolithic applications is that they are difficult to continuously deploy because you have to deploy the whole application for one change, even if it's a small one. The time it takes to re-deploy and start-up the application cuts into valuable time, thus decreasing productivity. Additionally, these huge applications are not resilient because one bug can bring down the whole application since it is all running in one process.

Microservices solve these problems through the idea that you should break your large application into small, decoupled, independent systems that connect back together to make your application work. The total functionality remains unchanged, but the application has been broken into manageable chunks. Each chunk is a service that can be developed independently by a team focused on that service. This means that the team actually understands the code base! Thus they can write, deploy and test faster, increasing productivity. The team can choose the language they want to write in or the newest technology that they want to use without being held back by the rest of the application.

Another benefit of microservices is that each service can be deployed independently. This feature is beneficial because now development teams can use the hardware that best matches each service's resource requirements instead of having to compromise on the hardware. Independent deployments leads to scalability because each component can be scaled appropriately, enabling efficient use of resources due to changes in demand. Additionally, the microservice architecture is resilient because one component failing will not take down the whole application as the containers are independently deployed.

However, microservices are not the silver bullet to software development architecture. Like all technologies, microservices have their drawbacks as well. Microservices can become very complex due to the distributed system. Integration, deployment, testing and management of the application becomes complicated when there is an increased number of services. For example, making a change across multiple services can be a challenge because of the dependencies between the services. In a monolithic application, you can change the modules, integrate the changes and deploy in one step. Testing is also simpler because you can launch an end-to-end test with minimal effort.

In a microservice architecture however, you have to coordinate the changes between services and plan out the deployment to roll out the changes. To test your change, you have to ensure that all the dependent services are working including the service you made the change in.

Additionally, in a microservice architecture, developers have to implement some type of communication mechanism between the services. This adds overhead to the application increasing the complexity.

To summarize, the microservice architecture enforces modularity which leads to individual services that can be faster to deploy and easier to understand and maintain. As with all technologies, microservices have their disadvantages as outlined above. As a developer/architect, it's important to understand which architecture is best for your project as sometimes a monolithic infrastructure will be the right idea and other times microservices will be the answer.

This is the third post in my "What is" tech blog series. I'll be writing more every week here and on myÂ blog!

What is an API?

Aditi Chaudhry — Fri, 07 Jul 2017 22:09:07 +0000

This article was first published on Medium. You can take a look at itÂ here

API's are the unsung hero of our connected world. They connect different devices and applications to each other enabling us to have the world at our fingertips. But what exactly is an API? The following is a high-level overview of what an API is. The implementation details will vary depending on the requirements and complexity of the system you are trying to build.

API stands for "Application Programming Interface." Wikipedia defines an API as "a set ofÂ subroutine definitions, protocols, and tools for buildingÂ application software". APIs are a wonderful tool for developers because they simplify programming through abstraction. The developer has access to the objects and actions they need and doesn't have to worry about the underlying implementation.

An API is the interface that allows software applications to communicate with each other. It is like a messenger that relays requests and responses between two parties. Let's walk through an example. Imagine that an API is a waiter at your favorite restaurant. You are sitting at the table looking at the menu deciding what to order. The kitchen, aka the provider, will fulfill your order. But how will the kitchen know what you want and how will you get your food from the kitchen? Enter your waiter, aka the API! The waiter takes your order (the request), delivers it to the kitchen and then delivers the food (the response) back to you.

Now, let's apply this to a real API example. Let's say we are booking a hotel for a trip to Disney World. The process for searching for a hotel online is similar to choosing an entrÃ©e on a dinner menu, except it's probably a dropdown menu. You choose the day you would like to check-in, check-out and other variables such as room preference.

In the process of booking your hotel room, you are interacting with the hotel's website to access the hotel's database to see if there are any rooms available on those dates and what the cost will be.

But what if you are using an online service that displays information from multiple hotel brands instead of just the hotel's website? Just like you interacted with the hotel's website to get the information, an application will interact with the hotel's API.

The API is the interface, like the waiter, that runs and delivers the data from the online service to the hotel's system over the Internet. It then takes the hotel's response and delivers it back to the online service. Through each step of this process, the API facilitates the interaction between the online service and the hotel's system. The same is true for all interactions between applications, data and devices - APIs are what allow devices and applications to connect to each other to move data from one point to another.

We have APIs to thank for the sites that provide us with the best deals on hotels, travel, etc. But more importantly, APIs have enabled us to live in an interconnected world.

This is the second post in my "What is" tech blog series. I'll be writing more every week here and on myÂ blog!