Caveat: The following blog is about a straightforward project; however, what's important isn't the technology. It's the process of understanding requirements and delivering to meet business demands.
This my fourth blog in this series and I want to talk Security. I've come across many situations where security can be treated like a visit to the dentist - with most people avoiding it unless they are suffering from pain.
Why is this such a broken relationship?
My experience with large enterprises is that the silo mentality creates invisible barriers. This behaviour along with overstretched security resources results in what feels like an internal security consultation team, instead of on-hand support, due to the security teams' limited time and bandwidth.
However, security is not an entirely innocent party here either. It's incredibly easy to say no to change; it's natural to say no, both personally and professionally. Also, there is an interesting tension between the demands of project delivery and trying to keep your organisation from joining an ever-growing list of companies that have been infiltrated, due to poor security implementation. However, by saying no to everything, you stifle progress, which also stifles innovation.
It doesn't have to be this way.
It genuinely doesn't have to be a bitter relationship. To heal old wounds, collaborate. Yes, that word again, regardless of how overused it seems. It's about engaging early and often. I frequently have catch-ups with security resources to understand their biggest fears and challenges and invite them to get involved in the design process. Having a healthy relationship means that designs with security involvement are much less likely to be blocked from deploying into production, in addition to the added benefit of a more secure platform. Win-Win all round!
It's about everyone in an organisation ultimately being on the same team; it's not 'them' and 'us', it's just the collective 'we'; working together to deliver business goals.
Werner Vogels, Amazon's CTO, last year stood-up on stage in New York and stated: "Security is everyone's job". He's right! It's security by design; it's security as code, it should be considered in every decision. You don't need to be a CISO to know about security. Put yourself in the data subject's shoes (Your customers), would you like your data protected by that design? Would you think it's acceptable to look at security in 'phase two'? Often it's easy to know if you're making the right decision by thinking: "does this feel right?"
Security is also not a mystical beast; it's about common sense controls. Take the principle of least privilege as an example; it means you can reduce the risk of a rogue account from making malicious actions, as the account would only have the permissions required to perform its function and nothing more. There's also plenty of help available too, from best practices which improve the design process, to compliance tooling to help the identification of security flaws.
I'm also a fan of Security-as-Code, a process where you bake the firewall rules, permissions and secure configurations into your Infrastructure-as-Code and configuration management. It works even better if it's a security resource that is writing the code, where they are embedded within the DevOps team. Having this type of multi-disciplined team means you get the best of both worlds, agile development and SME capability.
Summary
Your Security team shouldn't be your best friend, nor a foe, but a mutual partnership where they challenge you to ensure you are designing and building an appropriately secured platform. Working hand-in-hand, designing and building together to ensure the application and data area as protected as required, but using automation and tooling to ensure compliance and being able to safely make quick changes when issues arise.
No platform is flawless; its weakness just hasn't been found yet.
Theory over, next I want to talk about some of the security controls I've deployed in my project. Remember no platform is flawless; its weakness just hasn't been found yet.
The first thing to understand is the cloud shared responsibility model. As a customer, I have the responsibility to secure my data and my applications. The below diagram is an excellent example of what this means and who is responsible for each area.
In the context of my application, there are a few areas I can focus on which are.
- User Access (IAM)
- S3 (Access policies)
- GitHub Integration to CodePipeline
- SSL
I shared this code in a previous blog post and will refer to some of the code. https://github.com/colin-lyman/aceit-terraform-sample
IAM
Starting with Identity and Access Management, the first simple step is to secure the root account with MFA. I've also created a service account for Terraform which uses an access key and secret to call the AWS APIs. Due to the nature of what Terraform is used for it does require privileged access. However, you could limit the service account to operate only with AWS components it is going to deploy. You should consider the amount of overhead by managing policies at a granular level.
You'll notice in the Terraform sample in iam.tf that I've also created some additional IAM roles which are used to facilitate the CI/CD pipeline process. For those eagle-eyed readers, you'll spot some improvements that should be made, for instance, the IAM role policy for "codedeploy_policy" it allows GET and PUT requests, to name a few to any bucket which is not ideal; I better add a ticket to my backlog to review and improve this.
S3
As I've deployed a static website, you could be mistaken for thinking that the objects are world readable. However, that's not quite the case as I've configured the bucket policy only to allow CloudFront to access the S3 bucket. See https://github.com/colin-lyman/aceit-terraform-sample/blob/master/s3.tf line 30.
GitHub Integration
As mentioned in part 2 of this blog, I am using Terraform to configure CodePipeline's source as GitHub with OAuth credentials. You could argue that these should be stored in Secret Storage and not within a local configuration file and I would agree, however, my use case was about MVP and we should circle back to look at this further. The key thing is to note this as a task to come back to and make sure if it is done and not just forgotten about.
SSL
All website traffic for this website is over HTTPS using an AWS generated certificate (AWS Certificate Manager). These are free when protecting public endpoints like Elastic Loadbalancers, API Gateway, or in my case CloudFront meaning all traffic is encrypted in flight, and the identity of the endpoint can be verified by the user's browser.
Recap
Security isn't just a point in time configuration; it's a continuous monitoring and updating process to mitigate against the latest and greatest of attacks. The faster you can remediate against vulnerabilities the better your chance of staying one step ahead of your competitors who may not be as well protected.
Special thanks to Bob Thomson for acting editor.
If you want some help in adopting the cloud, feel free to reach out to me using the contact details below.