(Reading Time: 2.5 minutes)
Today I want to share an experience of how a small amount of training can help connect a collection of Cloud & Security concepts for a developing engineer.
QualiMente uses its Cloud Platform team skills matrix to guide its own professional development plans. One of our Cloud Engineers, Steve Sutton, has been interning with QM. He is with us full-time this summer working on our secret delivery and usage analysis projects. Steve just completed the AWS Security Fundamentals course to build his security skills. Steve offered some insightful observations on that learning experience and I asked if he would like to write-up and share them with this list. He said yes – thank you Steve!
As a manager, I’m stoked that he learned so much in less than 2 days and confident our project work will benefit. My favorite takeaways:
- Motivation: Each security service or feature maps to a governance domain which determines why you would do it
- Ability: There are a limited set of security services that can be combined to achieve certain goals and designs can be evaluated quickly
Here is Steve’s write-up :
On the Deceitful Complexity of Cloud Security
I have been learning about and developing cloud architecture for almost two years now. Last week I completed the AWS Security Fundamentals training and certification course. In my experience there has always been a daunting number of motivations that guide designs for a secure system. Some of these motivations have been obvious to me while others must have been pulled from thin air.
The training course places an emphasis on understanding IT governance and its importance. The course defines governance as the process to ensure effective and efficient use of IT in enabling an organization to achieve its goals. The eight governance domains were outlined as follows:
- Manage my IT assets
- Manage my IT costs
- Control Logical Access
- Control Physical Access
- Secure IT resources
- Log IT activities
- Monitor IT Events
- Monitor IT Resiliency
And then it occurred to me, these were the unknown motivations that I couldn’t identify! These are the bases that need to be covered when thinking about your architecture. These are the abstract roles filled by concrete technology like virtual private clouds, hardware security modules, or bastion hosts just to name a few.
What I appreciate most about the effort to define those governance domains is that the rest of us have a checklist to run through. As a matter of fact, AWS offers free and public audit checklists for managing existing systems. From a design standpoint, these checklists express what your system will be expected to do. Moreover, as someone with relatively little experience compared to others in this field, I am able to use these items as motivations for implementing complex solutions.
Contrary to what I thought, there are actually a finite number of features offered by AWS which means a system can only have so many configurations. This realization made me happy. A breakdown of services and features follows:
- 10 services to harden your system
- 6 services to create logs and events
- 5 services to store log files
- 3 features to protect network security
- 3 services for automation and notifications
Furthermore, the training connected each and every one of these services and features to their corresponding governance domains. So while the sheer number of services to implement is still very high, I have seen that they are not endless and why each one exists. And that has made all the difference.
#NoDrama
