Thinking Securely, in AWS.

Another stripe to the SecDevOps tiger.

Published in

The Startup

10 min readSep 15, 2020

Cybersecurity roles are expected to grow 750% in the next five years [1][2], now, if you are expecting that colleges, companies, and governments bridge the knowledge gap to fulfill those jobs, you’ve learned nothing from tech-history.

Those more than 5 million future jobs will be filled by high-driven individuals looking for a $99,730 yearly median-salary, in the US. [1][3]

But besides job stability and good earnings potential, there are plenty of good reasons to engage in a cyber-security related career:

Work for a socially responsible organization: Companies that invest resources in cybersecurity are, potentially, better intentioned in protecting their customer’s interests, they care for the organization long-term sustainability, have a defined vision, follow superior ethical practices, and generally are nicer people to work with.
Challenging projects and transferable skills: In the current tech innovation wave, the industries experiencing the highest growth are, unsurprisingly, the most regulated ones: Fin-Tech, Health Care, and shortly Government. Regulations involve meeting compliance requirements, auditing, and handling sensitive data, where the incentives for cyber-attacks are considerably larger. Curious individuals will like to learn that the strategies employed in one industry can be adapted to other industries, giving you great mobility and a variety of problems to work on.
Ownership and control of your output: contrary to Software Development where development is usually driven by the market, managers, or users. Security is legislated and more often than not, logical, there is an established “right” way to operate, while still allowing plenty of creativity and innovation with a rapidly evolving scenery involving Machine Learning bots and tools to help manage and monitor cloud infrastructure.

The industries experiencing the highest growth are, unsurprisingly, the most regulated ones.

Security Basics

I would argue, the transition to senior and leadership roles in Software Engineering comes in a great proportion from the methodologies employed to produce code: planning, designing, testing, and documenting are usually the mark-ups of experienced developers.

In the same way, the path towards Software Architecture requires a new skill-set involving thinking about system interactions, vulnerabilities, infrastructure resources, and cost management.

Thinking about security, is similar to the defensive strategies employed by Test-Driven Development .

Similarities with TDD.

In test-driven development requirements are turned into particular test cases, then the code is improved so that the tests pass.[5] The keynote, on TDD, is that first tests are designed, then code is produced. Now, TDD iterates in units called features or “User Stories”. On security, however, the basic unit of choice is a system or “micro-service”.

The security-mindset is architectural, risks are not assesed in isolation but rather holistic and cross-disciplinary.

Just as when doing TDD, the planning phase is not done exclusively by the engineering team but involving stakeholders, product owners & in some cases risk and compliance officers. After every potential risk is enlisted and assessed, actions can be taken to mitigate them. The Defensive Security Handbook[4] has 4 great examples, using fictional personas, on how to do so:

Risk avoidance: Deciding that storing Social Security numbers for customers is an unneeded process and discontinues the practice.

Risk remediation: Alex starts turning off open ports, implementing stricter firewall rules, and patching endpoints.

Transferring of risk: Ian outsources credit card processing to a third-party as opposed to storing data on-site.

Accepting risk: Kate knows that a certain endpoint has no access to other endpoints and runs a third-party application. This application has a low-risk vulnerability that is required for it to function. While nothing at that point can be changed or remediated with that vulnerability, the risk is low enough to accept.

Just as site reliability engineers have accepted that no SLA can cover 100% of service up-time. A well-sounded security strategy will also account for a margin of error or unpredicatiblity.

THE NIST Cybersecurity Framework.

The National Institute of Standards & Technology (NIST) has published a Framework for Improving Critical Infrastructure Cybersecurity[6]: “to apply the principles and best practices of risk management, security, and resilience, for any organization, regardless of size, risk, or sophistication.

They recommend five core functions to perform for a successful Cyber-security program: identify. protect, detect, respond & recover. To emphasize the last two of them: “respond and recover”, they prevent a common attack pattern that gradually infiltrates within a system until reaching the desired target.

A good Cyber-security strategy relies in a set of layers to surround and protect the sensitive data and resources.

It is in this regard, detecting, recovering, and responding to an attack is crucial, part of a specialty focused on responding intelligently to incidents.

Organizational values

As mentioned, the endeavor is cross-functional with the responsibility and operation shared across the organization. There is no better way to showcase this, than quoting the practices followed by an industry leader:

“Once a week, the CEO of AWS meets with senior AWS leaders to discuss any security issues and how they are being addressed throughout the AWS teams that build and operate our services”. [7]

Very impressive! The commitment, discipline, frequency, and priority they assign. Equally impressive is their day-to-day operations across their products:

“Also each week, the Chief Information Security Officer (CISO) reviews the progress of Application Security (“AppSec”) reviews, thousands of which we conduct each year.”

Just as in Software Engineering, code reviews are performed, routinely code is scanned to find, warn, and fix potential threats. Continuous improvement, is critical when doing security, as many cyber-attacks rely on public vulnerabilities found on Open Source Software.

A secure organizational culture would not be complete if the knowledge is not cascade, in this regard I find equally important to assess and complement new hire security knowledge, document best practices and what vulnerabilities to look during Code Reviews, as continuous training that can be done by attending virtual conferences & cross-company networking events or dedicated online communities.

Security in AWS

“A ship is safe in harbor, but that’s not what is built for.”
— John A. Shedd

Do not feel overwhelmed! The good news is that just as many other Software Development tasks, once you get to the cloud things tend to get simpler. In this case, the basis of Security in AWS is the Shared Responsibility Model where AWS assumes the risks on the infrastructure, hardware, and managed services also software, while your organization is only responsible for the applications deployed and the managed data.

AWS Shared Security Responsibility Model [8]

With that in mind, there are three simple steps a start-up can take to initiate their path towards a responsible and secure application management.

1. Configuring Permissions

IAM is the service used to grant permissions for AWS users, groups, and machines to use, access, and create resources. In the Security Pillar[9], part of the AWS Well-Architected Framework, the recommendation is to follow the least privilege principle. The principle consists of having a centralized “authorization repository” where the separation of duties is enforced, granting only the minimum permission for a given user to fulfill their tasks. A centralized repository facilitates regular revisions to continuously question and downgrade granted privileges.

Another well-established security practice is rotating credentials often, and enabling Multifactor Authentication, interestingly a good portion of cyber-attacks have a “social component” to them, where authorization is granted not through technical feats, but by negligence handling credentials and sensitive data.

Following the analogy with SDD, Secure Driven Development, when planning or provisioning for a new service, part of the assessment should consist of detailing what AWS services and instances are required and allowed to be accessed to meet the service requirements, this can be accomplished by defining specific IAM policies, roles and users for the service.

While getting deep in IAM can be intimidating, I find it no different than working with CloudFormation and is just a matter of practice and good study materials [10][11]. When working with permissions, besides IAM, it is suggested to consider and be proficient at other services like Cognito and AWS Cloud Directory.

2. Protect Data

One of the most common attacks in the enterprise world is related to data breaches[1][12]. But before jumping to the technical part of it, is key to understand, the implications related to the industry where the organization steers, what compliance requirements are to be met, and develop an inventory of sensitive data and cloud resources. In highly regulated industries, mapping these requirements often involves help from external experts and governmental advisors, and equally important is educating engineers, which often come from different backgrounds and industries on the topic.

In AWS, data encryption is “strongly recommend encryption for data-at-rest and in-transit”[7]. Depending on the service, AWS offers easy integration through Key Management Service (KMS), radically, AWS KMS is designed so that no one, including AWS employees, can retrieve customer keys and use them outside the service.

Another key, service when working with sensitive data is AWS Secret’s Manager which enables replacing hardcoded credentials and passwords, with API calls to retrieve secrets programmatically, adding an extra layer of security when accessing a database or third-party application. Secret’s Manager also has auditing capabilities, to trace who & when accessed the secret value with other cool features to restrict undesired changes to the secret values or periodically rotating them for extra security.

A third aspect to consider when protecting data is network access: from using WAF, a web application firewall, to mitigate the top 10 Web Application Vulnerabilities [13], or deploying multiple VPCs, Virtual Private Clouds, to restricted access and build the aftermentioned security layers. When designing VPC or any other semi-closed system, is good to think them in the light of Hexagonal Architecture where service entry points and outputs are delimited, with the core resources of the service lying on the nucleus.

3. Intrusion Detection:

The last step, and quite possibly the most complex one, perhaps, not impractical to implement across some organizations, it is, however, still important to know what are their components in the AWS cloud.

AWS Configure: the most basic, and essential detection tool, monitors changes to infrastructure, be it in the permission access for a database, a newly created IAM user, or simply spinning a new EC2 instance, changes in infrastructure are important to monitor as some attacks do not start from an outside threat, but rather, by the negligent or sometimes ignorant use of authorized access.

Logging & Monitoring: while a centralized log repository with analysis for intrusion detection feels utopic for most startups. AWS CloudTrail does provide useful information on who is making requests and accessing each resource, this can provide clues when looking for potential intrusions.

AI-Powered Tools: the most exciting part is left to the end, with the rapid advent of AI and a serious commitment by AWS is understandable that many tasks are outsourced to AI-powered tools to provide automatized scans for threats. Not only is it cost-effective, but anonymized data gathered across thousands of customers sets the stage for more efficient intrusion detection. Some of the tools championed by AWS include GuardDuty, Amazon Inspector, and Macie for classifying sensitive data. The invitation is extended to the kind reader that has reached the end to experiment with them and share their findings on the comments.

Conclusion

Yes, Cybersecurity is an exploding & profitable industry, and yes, it is not as daunting or hard as one would have previously imagined, however, the reasons to engage, educate, and develop secure software, shall not be motivated by the pursuit of profits but rather on the sincere intent of doing things ethically & rightfully. As we stand in the middle of a pandemic, with many people and countries suffering from social and economic turmoil, it is my conviction that as Software Engineers we are part of a privileged group, that has profited from the digitalization in our lives, the economies of scale and globalization. For me, the least we can do is an honest effort to deliver software that meets our customer needs, at best be pivotal, leading, and supporting social advancement in the search of a more equal, just, and free society.

Sincerely,
Santiago M.