“Secure By Design and Default” in Your Cybersecurity Team

What the Three “Secure by Design and Default” Software Product Security Principles Mean for Your Cybersecurity Team

Bad security happens because we protect only one attack surface at a time or when a new regulation tells us to. We are “Vulnerable by Design.” (CISA ).There is no way we can continue keeping products and even ourselves secure if we rely on humans to take action to keep their security posture current. “Secure by Design and Default” wants to change how we design products from the beginning of the process by injecting security from day one.

“Secure by Design and Default” is an approach to security product development where customer-centric security requirements are injected into product development from the beginning and products are released in a state where customers are secure “out-of-the-box.”

Many of us in the DevSecOps world already strive to do this with our own projects. In reality, our software supply chain relies on many open-source and third-party vendors to keep us afloat. Many of these software and hardware products require us to keep them current with security patches. I don’t know about you; product currency stories in our backlog usually don’t get the highest priority. Balancing priorities among customer features, security, and engineering operations means that security doesn’t always “eat first.”

“Secure by Design and Default” extends security into the product world. The intention of the “Secure by Design and Default” is to bring a set of principles and tactics to manufacturers and encourage them to “take ownership of improving the security outcomes of their customers”(CISA )

Now, I recognize that the intent of the “Secure by Design and Default” mission is to provide high-level principles and recommendations for technology manufacturers. However, I believe these very same principles and recommendations apply to our internal cybersecurity teams as well.

What “Secure By Design” Means for Your Cybersecurity Team

Cybersecurity teams have been created in a variety of ways. Sometimes they started out with a purpose from an Information Security team, other times, they were just a few security architects over in the corner rarely listened to.

“Secure By Design” infers that the makeup of your security team, processes, and tools should be defined by a set of preexisting set of standards and controls. Not all security teams start out this way.

The first step to being “Secure by Design” is to build a framework of rules to communicate effectively to your business/organization. Development and operation teams need to know exactly what security policies are in place, what processes they need to follow to be compliant, and what resources are available for them to use.

A more evolved method of “Security By Design” is to make the implementation of security frictionless. Once you have your policies and standards in place, there is an opportunity to automate your security policies. Ideally, security would have no additional actions that a user needs to make in order to be compliant with the security policy. Frictionless security doesn’t happen overnight, but prioritizing the processes that are used the most and reducing the most risk is where to start.

What “Secure by Default” Means for Your Cybersecurity Team

Building resiliency in cybersecurity teams has a lot of meanings. I like to think that each experience a customer, partner, or stakeholder has with cybersecurity needs to be “Secure by Default.” Having a focus on reducing or removing actions a user needs to do to be secure provides a better user experience. And with all things in life, a better experience leads to proper usage, higher adoption, and in turn, better security by default.

Truthfully, the multitude of use cases that need to be evaluated and improved is an organizational challenge. There’s only so much time in the day, and there’s one thing I’ve noticed about the security team, they have a process for everything. Improving the user experience of security will not be an easy feat, but over time as new processes roll out, it’s imperative that the user experience be a consideration.

What the Three “Secure by Design and Default” Software Product Security Principles Mean for Your Cybersecurity Team

1. The burden of security should not fall solely on the customer

There are three components to this principle. Focus on Customer Experience — Don’t let security be an impediment to using your products or services. The best security is one that doesn’t change the user experience for your customers. Users have an expectation of how much effort they are willing to put into using a new product or service. Unlike the IRS, most organizations cannot make logging in a multi-step ordeal. Security needs to be both present and invisible — If there is a process we can do behind the screens to make the customer’s experience seamless and easier, security should prioritize these tasks. Don’t let customer experience end up buried in the backlog to be purged. Take ownership of all your Customers — Don’t forget to include both internal and external customers of Cybersecurity. Internal customers of security include the employees of your organization. People are our biggest threat. By making security an impediment to their goals, we can unintentionally incentivize our own people to skip security processes.

2. Embrace radical transparency and accountability

Stakeholders tell cybersecurity that they what to know what they are getting for the money they are putting in. Don’t confuse this with the phrase, “What do you do here?” Two questions I see Stakeholders asking time and time again are: “What value are you delivering to the business?” — Stakeholders are not necessarily security experts. They do not necessarily understand that fixing a vulnerability improves the overall security posture and reduces the risk for the entire company. They do understand that if the risk is reduced, then the chance of an exploit could be reduced and/or the potential consequences limited. I like to communicate with my stakeholders in terms of their own goals. When a stakeholder gives me access to the objectives of their product and how they measure them, I gain valuable insight into what matters to them. This allows me to organize our security initiatives under their outcomes. By showing that security initiatives can influence their key results, I effectively show the business the value security provides in measurements that they understand and use. “Are you effectively delivering value?” — In addition to “delivering value to the business, it’s important to measure how efficient your work is as well. Knowing this information gives stakeholders confidence that security is delivering value creating a culture of improvement through using data to make decisions.

1. Key risk indicators — One of the most important ways cybersecurity should deliver value to the business is ‘Reducing Risk.’ Key risk indicators measuring each of your six cybersecurity postures is a great start to understanding your holistic risk posture. For example, measuring the number of applications with exploitable & critical vulnerabilities unfixed for more than 30 days gives a cybersecurity leader a general understanding of how many applications are not performing proper security hygiene. Using this data about the application security posture, leaders can create initiatives to change the behavior of application owners or developers. Some initiative ideas to mitigate this risk are to form a security champions team, automate vulnerability pull requests, and increase security training for developers. By measuring risk, we provide the data necessary to create new initiatives that further reduce risk.
2. Key performance metrics — The organization’s leaders strive to be efficient with their resources. By instrumenting our processes and tracking our velocity, we provide our business and security leaders with data. One great example of measuring our performance is to track the ‘mean time to response.’ For security operations, once a new vulnerability is identified in the industry, it’s up to our security teams to determine if the vulnerability is detected in the organization’s environment, assess if the vulnerability is critical to your security, and get that information into the hands of our developers as soon as possible so that they can begin the remediation process. Measuring performance provides transparency to how efficient our processes are. When they get slow, then it’s time to reevaluate them.

3. Build organizational structure and leadership to achieve these goals.

Organizations don’t change hierarchies frequently. I have found that it’s not even necessary. Shifting to a product-led security approach can begin as a small shift that grows over time. Product Mindset — The first shift toward implementing a product-led security organization is adopting a product mindset. Adopting a product mindset means we are primarily concerned with continuously delivering incremental value to the organization over time. The most common way to deliver measurable value is by a form of goal setting known as ‘Outcome & Key Results. Having a product mindset means that you deliver measurable expected outcomes rather than completing projects that may or may not accomplish what you set out to do. Align Security vision and strategy to the business — Most organizations have a vision statement that defines what the organization aspires to do. This vision leads to the yearly and quarterly goals. These goals, also known as outcomes, are how the business creates value. It’s up to security to align their goals were possible to the business outcome. These security outcomes become the strategic roadmap of how cybersecurity provides measurable value to the organization. I go into a deeper dive on this subject in “3 Tips for Aligning Business Vision to Cybersecurity Strategy .” Inject Security into the Product Trio — I am not advocating for changing product trios . I am advocating for having product managers inject security requirements into their products from inception. Cybersecurity needs to provide business product managers with a security framework so that they can incorporate security easily.

Final Thoughts

“Secure by Design, Secure by Default” really resonated with me at multiple levels. The approach of shifting the burden of security from the customer to the product itself provided a key lesson to deliver a better and longer-lasting experience for our customers.

As we build product-led principles into our own internal cyber teams, there is much to appreciate in focusing on our customer’s experience, increasing transparency, and aligning our security outcomes to business value.

To learn more about delivering cybersecurity value to customers, developers, and business stakeholders, check out my other articles on LinkedIn.

If you made it this far, please consider any combination of liking, commenting, or following me on LinkedIn.