What is secure by design and why should we adopt it?
The security community has been very focused on assessing, identifying risks, threats, vulnerabilities, misconfigurations, and the tools at their disposal have been growing and providing amazing and clearer insights and visibility into the risks, attack surface, and potential exposure and current attacks. Despite all these tools the number of breaches are increasing, the scale and extent of damages is also increasing. Perhaps, it is time that as a community we focus on the root cause of the problem and go beyond detection and incident response. It is time we start focusing on how, why and where the security risks are introduced into the code or infrastructure and focus on preventing the risks from being introduced into the system.
For that the community will need to focus on baking security in when the code is written and when the infrastructure is built, when the system is being built. Let’s take an example of a house, if you place a window right near the door, someone can smash the window and open your door. The architects must design in a way that such security design risks do not exist. Otherwise, one must spend a lot to either fix the vulnerability or mitigate it with measures such as hiring a security guard or implementing a camera system and so on. It is much easier if security is baked right in the architect’s design of the house. In much the same way it is much easier and has a better ROI if security is baked in when the cloud architects draw up the architectures for cloud deployments instead of spending 10-100x on remediations and mitigations. The ROI is clear; the bigger question is how to do it efficiently and effectively.
Let’s take another data point here. Veracode’s State of Software Security report 2023 highlights that almost a third of the software that is put into production has bugs at the time of release. Imagine if we would have built our airplanes like that or if we would have constructed our bridges like that! Would we trust and fly or drive over those bridges? But we are allowing software to be released with bugs! Now that we are going to allow software to control our cars, it is imperative that we fix this issue of releasing software with bugs, or we are going to see crashes and death as software starts becoming more pervasive in our day-to-day life activities!
Origins of the secure by design approach
To understand how we are going to bake security in, let’s talk about the origins and evolution of secure by design thinking and how this is going to help. For those of us who understand processes, controls and risks, know how risks are introduced into the system. It happens when the code is written and when the infrastructure or system is deployed. However, the engineering teams that write the code and build the infrastructure and systems are not security experts. The security community needs to help them understand security and be incentivized to build securely.
Engineering teams that write the code and the operations teams that build out the infrastructure and systems to support them, are usually under tremendous pressure to code and ship the products and go to market fast. Developers want to build the next coolest feature, and in fact they are measured on how many features they push out or help push and let’s face it, rightfully so, because if there are no features, no product, there is no revenue and no business to secure! So the big question is, how do we get them who are focused on shipping that product out and keeping business agile into thinking about security? Making the engineering and operations teams who are building at a speed of 100 miles an hour to ship that product or provision that infrastructure to get the product to market and generate revenue, making them think about security is hard because security typically needs one to slow down and think through the process.
The more important question is how do we marry those two things together, need for speed and agility, and the need for security and compliance. Making both happen is very important in building a successful secure by design initiative within your company because you are going to need the engineering and operations teams buy in and the business buy in and will need to show that security is a value driver, it is valuable to the company to think about security by design, and baking security at the time they are coding or building the system or provisioning the infrastructure can be seamlessly and efficiently done without slowing them down.
Hopefully the number of breaches and the extent of damage by the breaches with potential for impacting our lives directly like bugs causing car crashes or the latest healthcare hack shutting down care in a lot of places, will bring about the culture change required to adopt new paradigms like secure by design as the tone at the top changes and it starts becoming a Board imperative. By bringing in automation to the secure by design approach, one can indeed overcome the disconnect between security and business need for agility, making it seamless and thereby making buy-in from business and engineering much easier and in fact a no-brainer.
Compare and contrast secure by design and zero trust
Let’s step back and understand the origins of the concept of zero trust. Funnily all of us in the security community are always a bit more paranoid than the general population, consider it a side effect of the profession! So most have been practicing zero trust in more ways than one for a long time. Take the concept of “implicit deny” rule in our firewalls which has been around for a long time. Think about zero trust as implicit deny when access to any resource, data or compute, is requested. That means you put systems and processes in place to verify the identity of the person or principle accessing sensitive resources every time the access is requested. This can be implemented as zero trust network access or zero trust architectures.
To understand why this concept has gained prominence, one has to understand how we have gone from having perimeter based networked systems with trusted interiors to complex, hybrid, remote first, bring your own device, cloud-based, myriad of SaaS applications used by business units, decentralized IT infrastructure scenario. In the previous scenario, once inside the perimeter, physical perimeter or the logical firewalled perimeter everyone could access the servers, once inside you were trusted it might be a little mushy it was like an M&M, hard on the outside and a little mushy on the inside and we used to call that trust but verify everyone inside is trusted, you could vpn in and now you are fully trusted inside. With the increasingly complex decentralized scenario with no clear perimeters and boundaries, it has become critical that we check every access request to a data resource or compute resource. That led to the expansion of the depth and breadth of the implicit deny concept as it had to be applied for every access request. And that is how we got to zero trust, check every access request concept.
In fact, in some cases even the centralized CIO organizations have disappeared and unfortunately along with it the operations discipline that was built over time. Each unit sometimes manages its own infrastructure. Maybe the engineering teams are managing their own infrastructure cloud and have devops or cloudops teams managing the infra. Or business units have their own IT systems and teams, creating several shadow IT organizations in the company. But these teams may not be trained in the operations discipline of a centralized CIO organization nor be experts in security and compliance, adding to the complexity of modern-day IT in companies.
So, identifying all sensitive data resources and compute resources and implementing a system of zero trust which will implicitly deny before verifying every access request has become a way forward to ensuring all systems and sensitive resources are protected no matter where the employee is located and where the access request is coming from.
Secure by design and zero trust
Implementing the concept of zero trust may involve use of a zero-trust network access solution or implementing zero trust architecture that you can apply when you are building out your cloud infrastructure, and this can happen if you have adopted the secure by design approach and are thinking about baking security in, whether it is zero trust or otherwise, when you are building the infrastructure. Zero trust specifically can include various techniques including but not limited to isolating everything and sandboxing or micro segmentation and identity governance, verifying the identity of the person or application requesting and continuously monitoring every session.
Taking one step further, as a part of your secure by design approach to building systems and infrastructure you may use zero trust architectures or implement zero trust network access solutions or implement other defense in depth solutions. Basically, by following secure by design philosophy, when you are building your cloud infrastructure you will be considering these approaches zero trust or defense in depth and bake security in your cloud architecture designs.
Challenges to implementing secure by design
That is a million-dollar question. Going back to where we started and remembering how risks are introduced, where business necessitates speed and getting security means slowing things down a bit. For years together security teams have tried to insert themselves early in the processes, in the meetings, provided best practices, hardening guides so that systems are built securely but because the engineering and operations teams need both training and automation that bakes security in their routines, in their jobs to be done workflows, true success remained elusive. This is especially true more so for infrastructure than application teams, where the devops, cloudops and security teams are far more resource constrained. While we need to enhance the operations team’s security expertise, the security teams who can support such transfer of knowledge are themselves resource constrained. To even imagine that the security teams can have the time or expertise to read and review the infrastructure as code files when the operations teams are building the infrastructure within the time constrained laid down by the business is near impossible. All this means we are full circle on security being reactionary and detect oriented, and companies unable to build things secure by design right at the start.
To champion security by design day zero, while ensuring that business and operations get to ship the product on time, security must be seamlessly integrated in their jobs to be done workflows. Automation is the critical missing piece in the jigsaw puzzle. We start with a culture of secure by design flowing from the top, and investment in automation to seamlessly make it happen. A bottom-up push where devops and security come together to automate and integrate security in existing processes in a manner that they stay aligned to the business need for agility is what will make secure by design a reality. Then hopefully Gartner will create a hype cycle or make it a part of a hype cycle and all vendors start talking about it. This podcast is a great start!
When aligned with business need for agility, security becomes a value driver not a tax because now they can ship that feature, ship that product out and get the system up and running fast and secure. That is where I think you know companies like Invi Grid, a little bit plug here, come in. With Secure by Design hyper automation you become a value driver for the business otherwise you are still reactionary and still everybody is avoiding that security person and still saying that security is slowing us down. When security is implemented by design with hyper automation without slowing down developers or devops teams, in fact enhancing, empowering them, to move fast, to ship fast, and to sign deals faster because they're already audit ready and compliant day zero, it suddenly starts making business sense. That is how our customers start realizing there is immediate ROI with this.
Other advantages for companies adopting secure by design with seamless integration are reduced insurance premiums, cost savings from reduced costly remediations, and productivity gains, time savings due to hyper automation as operations teams are now not spending time on undifferentiated, mundane, error prone tasks of coding for infrastructure configurations that meet security and compliance standards which has now been hyper automated but instead focusing on more higher order strategic tasks such as finalizing the architectures, optimizing cloud performance and costs etc. I wish there was a trust mark like the Cyber Trust Mark for IoT devices you mention for secure by design cloud practices followed! Currently it is the Invi Grid shield!
How do people reach out to you?
Best way to reach us is via our website contact form, or LinkedIn, or email info@invigrid.com
Final takeaways
It is time to think about security on a first principles basis, understanding the root cause of the issues we are seeing and applying first principles based secure by design approach. Let’s not over engineer security, what we need to do is re-engineer security from ground up and that is secure by design at the time the app is written, the system is built, or the infrastructure is provisioned, and you will save a lot of money down the road. So, don’t over engineer, re-engineer!
Comentarios