We’ve moved from hub and spoke network technologies, to servers, to virtualization, to cloud, and now we are graduating to container technologies using Docker and Kubernetes.
With this new evolution in technology brings new security review philosophies and approaches. It requires a new skill-set and experience.
One of the most exciting moments I had when a Docker and Kubernetes project landed on my lap was this realization,
“It’s just an API! It’s literally just a web page, being hosted on HTTPS with no visual interface.”
Does that make sense? It made sense to me, and I don’t know without having that realization if I would have had the strength to move forward to try to secure the project. That’s because I initially felt overwhelmed and stressed out. I feel the weight of securing the businesses I’m serving. And with every new technology, the boundaries get pushed further out. (I miss the days when our network wasn’t even connected to the Internet).
Since then, I’ve had many more realizations like:
“It’s just a webpage running over HTTPS with no visual webpage, but… it also has a management API web portal exposed.”
“It’s just a webpage running over HTTPS with no visual webpage, but… developers connect to the containers over default SSH.”
“It’s just a webpage running over HTTPS with no visual webpage, but… if the code repository is compromised then the whole production cloud is compromised.”
I could continue to share the epiphanies I’ve had, but I’ll spare you the time.
Let me premise my security philosophy on this;
Orchestrated container environments hosted, or in the cloud are hard enough for developers to build, configure, and move to production. This difficulty often results in most of the defaults being accepted across a range of toolsets and technology. Defaults are not good for security. The complexity of successfully moving a system to production moves the finish line to ‘code is in the cloud‘ instead of ‘the system is live and secure’.
Do we agree with the above statement I’ve made? If yes, continue reading. If no, this is not the article for you.
So what do we do about it?
I will attempt to cover my security philosophy at a high level and save the individual security concerns for future articles that compliment this one.
1. Data Classification
Develop a process to identify what your business deems ‘sensitive’ and ‘confidential’, public, and internal. Set definition to each of them, and then outline how that information and with who, and under what circumstances that information can be shared.
Visit our blog article, developing a data classification guide for more information.
2. Data Workload Guide:
The next step is determining what classification of data you will allow being hosted externally or in the cloud. This is ultimately a charter of your business stating where secure data and workload can be hosted. This is a security appetite and risk decision that needs to be made at a leadership level.
3. Approved Technologies:
There are two approaches to this. One is letting the developers use whatever they want so that they can move at the speed of the business. I call that the ‘speed of b.s.’.
The second, and my preferred is working with the developers to build an approved technologies list. They (developers) should know at the beginning of the year what they are going to be working on, and what technologies they want to use for that initiative and project.
Your goal is deep dive into those technologies and find resources on best security practices. Built a document of security hardening, configuration, and processes and provide ha to the developers for reference and expectation. then test that expectation.
For example, if the developers tell you they will be doing an application deployment using cloud containers, then ask the following questions:
What cloud platform are you planning to use? Google, Amazon, Azure?
What container technology will you use? Docker, CRI-O, RCKT?
Will you be manually deploying containers, or using orchestration? IF so, what orchestration will you use? Kubernetes?
Based on those questions and answers you should form a proposal to the developers and leadership that security will prepare a best security practice document for :
- Docker containers
- Kubernetes
- Amazon AWS
4. Compliance review
Next, check with your compliance department and review regulatory requirements to ensure that what the business is planning to do can be done with compliance findings and regulatory fines.
5. Data Workload approval
Next check what classification levels of data will be contained in these applications in the cloud. Check with the selected vendors and ensure they support that level of data classification in their enrollment.
* Some vendors explicitly say they are not approved for ‘confidential‘ data and it should not be placed here.
Then reference the Data Workload Guide we covered and step two and ensure the business has approved supporting this level of classification in the proposed environment.
Now that you have your philosophy outlined and you know what data is going to be hosted where, and you know what technologies are going to be used, and you have business sign off and approval you can start working on security controls and capabilities.
6. Security Controls
There are two approaches to this stage;
A. Defensive Approach: Start with the data and follow it from the developer and database out to the cloud.
B. Offensive approach: Start on the outside and ask the question if you were to get a foothold, what could you do and where could you go. Work your way to the inside until you have the data, comprised the integrity of the application code, own the orchestration, or elevated privileges.
Summary
In the next series of blog articles, we’re going to launch off this example to move forward and start to outline the security controls for containers, orchestration, and cloud environments at a platform level.
It is critically important that this security approach and philosophy was outlined first. Without it, there is a temptation to just start ‘securing’ it. That approach never works.
Bio:
Asher Security is a Minnesota Cybersecurity consulting and advisory firm focused on helping businesses reduce risk and lower cost by partnering with them to mature their security program.
Recent Comments