Last updated at Tue, 20 Aug 2024 19:37:28 GMT
Do your tool diligence
Convincing people to sign off on big cloud security spends is, most assuredly, a never-ending process. Because every so often (be it in 6 months, 1 year, 2 years), your security organization will have to pitch to the check-writers all over again. Of course, we all know it’s worth it to protect the business and infrastructure from catastrophe and keep shifting left into cloud enablement and scale.
The right cloud security tool will ideally serve the larger DevSecOps organization. Therefore, it only makes sense to have conversations with team members and decision-makers from development and security so that the ensuing workflow shift goes smoothly. In this way, developers can begin building security processes into their workflows, with security personnel providing checks, oversight, and evaluating Infrastructure-as-Code (IaC) templates in kind. But hammering out a smooth working partnership between these organizations comes later. Let’s first take a look at 5 key questions to answer before shifting (left) into cloud overdrive.
What clouds will you use in the future?
Sticking band-aids over soon-to-be-out-of-date processes is one way to accomplish cloud security goals. That’s assuming those goals are short-term. A tool that supports only your current provider or environment will quickly render itself obsolete as an organization builds into more clouds.
While using native Cloud Service Provider (CSP) tools will help protect your proprietary data and processes, leveraging multiple public clouds will require ongoing visibility. The responsibility of protecting end user data, applications, operating systems, endpoints, and network traffic will lie with your security team. To further complicate matters, taking on new partners anywhere along your supply chain will always present new risks, vulnerabilities, and challenges such as the following:
- Disjointed cloud-based security tools
- DevOps processes that deploy application code daily or even hourly
- Security information silos that make it difficult to respond to attacks
- Attacks focusing on cloud platforms
What IaC tools are you using?
Two things to never do: Don’t needlessly drain developer energy and don’t make security and compliance needlessly complex. Of course, this is easier said than done. Combining multiple IaC tools will inevitably lead to cloud security chaos of one sort or another. Minimizing the number and instances of these tools will help to increase flexibility and accelerate productivity; it’ll also just make people happier.
The ability to quickly discover and remediate vulnerabilities in cloud infrastructure is key when ramping up to a Continuous Integration/Continuous Delivery (CI/CD) pipeline. With IaC tools like Terraform or ARM, security and monitoring are naturally integrated earlier in the process so that quick changes close to runtime have a smaller chance of being security-related.
Who drives the CI/CD decisions?
That’s easy: the developers do. If security is, for whatever reason, out of lockstep with DevOps, then it stands to reason that limited visibility would render security and compliance tools less efficient. For example, when CI/CD pipeline tools change quickly, the need for code deployment speed might hamper efforts to catch bugs or vulnerabilities earlier, especially if many of those dev processes are automated.
In an ideal scenario, developer, QA, and operations teams have many CI/CD processes automated, including handoff from one team to another. It only makes sense for security to be part of early conversations on what monitoring and remediation tasks DevOps will undertake as they’re writing code. Lots of those tasks will indeed be automated, so that learning isn’t too much of a curve and deployment can happen on time.
Would you rather be proactive or reactive?
The nitty-gritty question is: which one do you want to do more of? It will never be possible to catch every bug, vulnerability, or issue prior to runtime. Many organizations are still only beginning to grasp the potential of the scale that cloud can enable, and are thus at different points in their CI/CD pipeline and Software Development Life Cycle (SDLC) journeys.
It’s important, however, that security and compliance teams remain consistent with policy definitions through the development process. It’s understandable to want to reach that speedy software potential, but meticulous planning is still necessary.
Will you need to liaise with outside teams for policy context?
This refers to the overall purpose of the application being built. Is it specific to the company’s industry? For instance, if public clouds will be involved in storing and transacting with customer credit-card numbers, then it will be key to speak with internal experts about how to incorporate PCI DSS policy-enforcement guidelines into the security process.
It’s very likely that an organization will run some processes in public clouds and some in private clouds. Which one they’re using will dictate the level of policy enforcement.
The science of exact
It’s rare that anything is an exact science, especially as it comes to cloud infrastructure that you’re continuously changing to meet shifting business demands. It is important to carefully consider your current cloud security needs and anticipate how they might change in the near future. Rushing the process will only end in later shortcomings. So ask yourself—as well as any and all stakeholders—the right questions that your future cloud security solution should answer.
Want more context on shifting left with cloud security and how it affects developers, security teams, and the larger business?
