The methods and techniques used for information security over the last two decades like firewall rules and log analysis is still a reality in the near term for cloud security, however, template-based design and security as code (SaC) is quickly emerging as the future of cloud security.
In enterprise DevOps and DevSecOps teams, we are already seeing how Security as Code (SaC) is directly impacting the CI/CD Pipeline, Infrastructure as Code, and Serverless Computing.
What is Security as Code (SaC)?
Because of the API automated code driven approach for developing, deploying, and managing cloud computing environments, Security as Code (SaC) is the logical and driving force in the future of application and cloud security.
Security as Code (SaC) can be described as the practice of building security into DevOps workflows by mapping out how changes to code and infrastructure are made and finding new places to add security checks, tests, and controls without introducing unnecessary costs or delays.
Developers are already defining infrastructure using code with Infrastructure as Code (IaC) and the same approach will bring security to the speed of DevOps.
To get started today with Security as Code (SaC), developers and cloud security engineers can begin integrating security policies, tests, and automated scans into the CI/CD pipeline and code itself. Testing should be automated for every code commit in the CI/CD pipeline with the results made immediately available for developers allowing them to remedy the identified gaps.
By bringing security scans to code as it is written, development and security teams will save a lot of time and money by streamlining the review process later in the software development lifecycle (SDLC).
Get My Free Cloud Security Journal
Why is Security as Code Important?
Security as Code (SaC) is key to moving from a classic DevOps approach to a new DevSecOps model.
Security needs to be defined at the beginning of a new project and codified for repeatable and consistent use by developers. We have to make it easy for developers by giving them self-service options to ensure their code is secure at the time of development versus waiting to later stages of the standard SDLC.
By pre-defining security policies, a boost in efficiency can be immediately recognized by most organizations much in the same way that programmers benefited from object oriented programming languages decades ago. Once functions were defined and verified, they could be used in libraries over and over again which boosted efficiency and security. This same type of approach is the future in cloud security and will be known as Security as Code (SaC).
By using pre-written security policies in the cloud computing environment as reusable objects just like programmers do in object oriented programming languages, we can automate processes that boost efficiency and security checks on automated processes to prevent unnecessary outages or security incidents. The majority of issues can be identified in the staging environment and save a lot of valuable time troubleshooting or fixing unnecessary errors and issues.
How To Get Started With Security as Code (SaC)
I previously mentioned that Security as Code is really the new DevSecOps model. Security needs to be transparent throughout the SDLC and ensuring developers and security engineers speak the same language is a key to faster adoption and integration within your organization.
Security engineers need to understand how developers work in the cloud environment and leverage this insight to build security controls into the SDLC. This is the basis for Security as Code (SaC).
It is just as important for developers to remain open minded to new tools and processes within their development processes that will ultimately increase the security of their pipelines.
Security as Code (SaC) gives pragmatic meaning to the concept of DevSecOps, but it should not be the end goal. Ultimately, SaC is simply a means to get the right people on board with integrating security throughout the entire SDLC lifecycle and at the beginning versus treating security as a bolt on at the end.
If you are already familiar with Infrastructure as Code (IaC), then this is a great place to get developers and cloud security engineers working together so both groups have a clearer understanding of how software development and security policy objects in the cloud can be codified into their workflows.
Six Easy Steps For Getting Started With Security as Code (SaC)
1 — Automate security scans and testing to include static and dynamic analysis and penetration testing within the CI/CD pipeline so they can be reused across all projects.
2 — Design and build a continuous feedback loop for developers by allowing them to remediate identified issues while coding. Not only is this a huge efficiency boost, it also helps developers learn security best practices.
3 — Monitor and evaluate automated security policies by building checks into the process. At a minimum you must verify that sensitive data is not accidentally shared or published.
4 — Take the object oriented programming approach to automating complex and time-consuming human-driven tasks such as manual testing.
5 — Implement and use a staging environment as part of the standard SDLC to allow for a proper security review before every code commit.
6 — Create a continuous monitoring process alerting developers and security engineers about red flags. A good example of this is GitLab’s Security Dashboard.
We need to shift our security mindset toward components and software defined objects in an automated environment. Just like in object oriented programming, we can design a cloud security feature (object) and it can be evoked many times at the speed of business.
Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.
Stay Connected With Tim Layton
Get My Free Cloud Security Journal
COMMON CYBERSECURITY RISK TERMS DEFINED
Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)
Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)
Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)
Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)
Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)
Likelihood: chance of something happening. (ISO 27001)
Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)
Risk: effect of uncertainty on objectives. (ISO 27001)
Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)
Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)
Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)
Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)
Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)
Get My Free Cloud Security Journal