When an organization commits to DevSecOps, a fundamental shift takes place across teams. Security becomes everyone’s responsibility. From the beginning of the development cycle, code is reviewed, audited, and tested for security issues. Those issues can be resolved early at far less cost. At the same time, DevSecOps helps improve software consistency, shorten time to market, increase productivity, and improve governance.
That’s our goal at Modzy®. We want our development teams empowered to deliver better code faster than ever. We also want to avoid security issues. Trust is a business imperative and rebuilds are expensive; we’re after efficiency and effectiveness for our organization and Modzy users.
There are many decisions that can help mitigate risk as you design your DevSecOps process. While there’s no magic answer, we found success by relying on three fundamental security principles and applying them to our design thinking for our DevSecOps. While every organization needs to consider its own culture, current processes, product requirements, and operations protocols, these principles will help anchor your strategy ahead.
#1: Confidentiality – Know what secrets you need to protect.
First, we considered what parts of our software delivery process might need to be confidential. We asked ourselves, “what do we really need to protect?”
This may seem obvious. However, it is important to devote significant thought to this question early and often. We considered the obvious, like what secrets we wanted to protect, as well as the downstream effect of protecting the things that have access to the secrets.
Our CI/CD tools inevitably have various levels of access to our environments. Certain repositories in source control had information about our environments, so we needed to afford those tools the same level of protection as the environments themselves, otherwise our tools could become a vector for human error or malicious intent.
It was also important that we considered what were our most valuable, or most risky, assets. These were things like Intellectual Property related to patents or proprietary information. Or software that is export controlled, internal security code for our product, or our various environment configurations.
Since Modzy was born as a remote-native company, we needed to consider not only what to protect, but who and where to protect it. Many who transitioned to majority remote work did not, at first, have all the VPNs, network and content monitoring, and centralized endpoint protection for all remote workers to match the setup you may have had in your corporate office.
Even with these protections in place, your teams are still working on untrusted or even hostile networks (like coffee shops) as well as potentially on unmanaged personal computers and mobile devices. Care and consideration must be taken to ensure that a compromised home computer or network does not put your confidential information and assets at risk. That is the “where” that you need to be protected from.
It’s also important to consider “who” to protect from. When all your developers are remote anyway, it becomes possible to pull talent from a larger pool than traditional recruiting. A lot of talent can be found through gig economy workers, off-shore and near-shore contractors, and more. Consider what aspects of your information and tools might require different levels of access: things like source control, build systems, artifact repositories, wikis, and document libraries, for example.
#2: Integrity – Verify artifacts to validate outcomes.
The Integrity principle requires the data about your information and systems to be accurate and reliable. So we next considered what parts of our process might require integrity checks. Again, we began with the obvious:
Know what’s being shipped.
We wanted to be able to trace back everything to a particular commit in the source control and have references to the results of every unit, integration, security, and penetration test that was performed along the way. We gained the maximum assurance that we were shipping exactly and only what we intended to ship. This means that we also needed to:
Know what tests to perform at each stage of the delivery process.
As we thought about our process, we had to decide what tests are appropriate for our product. It was also important to ensure that we could:
Verify test results before moving on to the next delivery stage.
Testing alone is not enough. We needed to define success and failure criteria for each test and deny artifacts to proceed further if a test failed our defined threshhold.
It was also important to us to ensure that our artifacts could not be modified or replaced after our verification checks took place. It does no good to verify your artifacts are free of vulnerabilities or bugs if they could be replaced mid-stream by something that hasn’t undergone full testing and validation.
Ultimately it was about establishing a provenance for each of our artifacts by the time they reached production. We wanted to have a full, verifiable history of each artifact and the confidence that nothing out of process occurred along the way.
#3: Availability
The third principle of security management is Availability. This tenet asserts that a computer system is available or accessible by an authorized user as needed, and that the system operates as expected. Denial-of-service attacks and other threats to data loss continue to proliferate at an alarming rate. So our key takeaways for monitoring include:
- Define your failure domains and remove single-points-of-failure
- Establish a back-up / replication strategy for your data
- Create alerts for critical issues
- Have a disaster recovery plan and practice it regularly
Monitor everything considered important.
As we increasingly rely on automation to achieve our goals, we can only be effective when everything is running effectively. We make sure that every critical piece to our process is monitored for proper functioning and to alert the appropriate people when anomalies are detected.
Security essentials and empowered developers breed success
Modzy was built to help organizations attain huge breakthroughs in AI deployment and governance. To do that successfully, we must not only practice what we preach, we want to show others how to design a DevSecOps process that works for building amazing products.
Missed the first blog in this series, Lead with DevSecOps to lower risk and raise value? Be sure to check it out and stay-tuned for the next blog in this series, Best Practices to Integrate DevSecOps.
This blog has been republished by AIIA. To view the original article, please click HERE.
Recent Comments