Security by Design and Default, Limits Human Error and Empowers Agencies

Attacks by bad actors are relentless, and despite compliance standards like FISMA and FedRAMP, breaches still happen due to both technology issues and human error. To combat this, Security by Design and Default (SbD-D) makes cybersecurity something to opt out of, instead of opting into it. This approach fundamentally alters the way we look at cyber defense, as disregarding safeguards now becomes an active choice, not an unforced error.

Microsoft research found that there are approximately 921 password attacks per second—a 74 percent increase, year-over-year. But even if there were no passwords anymore and everyone had phishing-resistant identities, agencies would still be at risk. Attackers are opportunistic, always looking for the easiest path into your systems. SbD-D gives agencies and industry a powerful defensive toolset.

Limit vulnerabilities from the start

If every new piece of technology agencies deploy is built to be secure from concept to implementation, IT and security teams only have to focus on keeping them secure from that point forward. This is the goal of Security by Design, which addresses several concerns at once:

● Third-party or open-source code, often used to speed development or add exclusive features, needs to be rigorously tested at every stage of development.

● The software supply chain needs to be validated and documented. Capturing every component and decision made throughout the software development lifecycle, using a tool like the open-source Software Bill of Materials (SBOM), helps pinpoint and mitigate issues.

● The development environment should follow Zero Trust and defense-in-depth principles to protect against damaging code being introduced at any stage of development.

Security by Default takes a similar approach. Essential security functions are enabled out of the box, then fine-tuned or turned off to suit the agency’s operational needs. Security settings and practices can then continue to change as the threat landscape evolves.

Obstacles to adopting SbD-D

So, why isn’t SbD-D the standard across the tech industry? There are three prime reasons:

1. Culture and human nature

Convenience frequently outweighs security. Turning on security features by default for all users can lead to risky workarounds and shadow technology. Staged rollouts to smaller groups of users, coupled with positive reinforcement, can help with acceptance.

2. Prevalence of legacy technology

Many essential Industrial Control Systems (ICS) and other Operational Technology (OT) aren’t likely to be modernized anytime soon. These systems require additional vigilance and layers of security.

3. Pace of transformation

Budget limitations, leadership priorities, and resource constraints are just some of the obstacles to modernization. Plus, there is a misconception that “security equals slow.” While it may take a bit longer to develop new software using secure practices, it represents a fraction of the cost of cleaning up after a major incident.

Fortunately, as more systems get updated or replaced, there will be more opportunities to introduce products built and implemented using SbD-D.

Agencies can benefit from industry’s experiences

By openly discussing their own security journeys, technology providers can build stronger relationships with their government customers and model success. Agencies should standardize on this transparency from industry partners.

For example, Microsoft adopts the mindset of being “customer zero” which means—designing, building, and implementing security solutions internally first. From the establishment of the Trustworthy Computing Initiative and Patch Tuesday in 2002, extensive contributions to pioneering the Software Development Lifecycle in 2008, and the inaugural Microsoft Secure Conference in 2023, Microsoft showcases they are not just a security company, but also a secure company, one that can share real-world experiences with agencies on how to best implement SbD-D technologies.

But a secure ecosystem requires coordination and cooperation across the industry. Protecting the software supply chain is called out specifically in the president’s cyber Executive Order 14028, and SBOM puts this into action for any developer through an open-source solution. SBOM is also a best practice that helps ensure the integrity and transparency of the development process—one that all developers should consider and a standard that agencies may soon require.

Driving toward a secure ecosystem

Realistically, smaller technology developers may not be able to implement SbD-D at the same speed and scale of the largest providers. But ultimately, SbD-D will become table stakes, as customers will come to expect it from their providers.

Of course, SbD-D products are only part of the answer. It will still be necessary for agencies to monitor, patch, maintain, and actively protect enterprise systems and data. As always, security is a team sport: industry builds better solutions while working with agencies to improve trust and confidence—and together, take steps to block bad actors looking for the next, easiest path in.