Our most recent security awareness training for the entire Affinity team was about email security. To emphasize a key point on the state of email security today, I took the team on a journey back to the origins of the Internet. The key point was this: many of the systems and protocols we rely on today were NOT designed and built with security in mind. “In the old days,” early users of the Internet were a close-knit group, each with their name and contact information in a printed-and-bound directory – far from the ubiquitous, anonymous, interconnected world in which we live in today. Applying security to older technology required patches, bolt-on components, and workarounds. Email is the ultimate example of an older, widely adopted, technology that we must work at to make secure today.

We cannot afford the risk of continuing in the old approach of developing software and systems. Building something quickly to prove a concept and “make it work” before going back to “make it secure” simply fails. The new approach is to make new software and systems secure from the beginning and to enable security features by default – what some describe as opt-out rather than opt-in security. There are two concepts here: Secure-By-Design and Secure-By-Default.

Secure-By-Design

The Secure-By-Design approach places security as a fundamental aspect of the software or system being developed, making security a core business goal. This is determined in the earliest design stage before development even begins. By making security a key feature, it gets managed, tracked, and measured like all the other key features in software or system being built.

Secure-By-Default

The Secure-By-Default approach enables all security functions in new software or systems so that they are fully secure upon initial setup. In the past, one would need to perform the initial setup then perform “hardening” steps to make the software or system secure. Being secure “out-of-the-box” means that the system is already hardened, and one is safe to start using it without security concerns. In the case that some security features are too strict, one can lessen or opt-out of certain features based on business needs.

Do you build custom software?

If your business performs custom development – either for internal applications or customer-facing ones – a new resource is available specifically for you: The Cybersecurity and Infrastructure Security Agency (CISA) released a whitepaper in April addressing the concepts of Secure-By-Design and Secure-By-Default. In CISA’s whitepaper is guidance and helpful recommendations on how to implement the principles in your organization.

Among the helpful recommendations provided in the whitepaper are specific tactics and technical controls developers can implement. While too specific to mention them in this forum, there are three principles defined in the whitepaper that are important to note when it comes to building secure systems:

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

2.     Embrace radical transparency and accountability.

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

What if you don’t build custom software?

If your business doesn’t perform custom development, it certainly uses software and systems provided by others. Do they implement the practices of Secure-By-Design or Secure-By-Default? If these vendors provide software or systems that are business-critical for you, then they make up part of your third-party or supply-chain risk. It’s important to know how these vendors protect you and your data.

How can one assess the security of a third-party vendor? What are the best practices for identifying and mitigating risk for software and systems run by your vendors? Here are a few suggestions:

1.     Develop minimum requirements for your strategic vendors; this could include:

a.     Guaranteed uptime, usually defined in Service Level Agreements (SLAs)

b.     Authentication capability (multi-factor, single-sign on, etc)

c.      Certifications and Accreditations (example: require SOC2)

2.     Ask the vendor about their security program and incident response

a.     Do they have a business continuity or incident response plan?

b.     What is the incident response procedure?

c.      Are we provided specific contacts for incident reporting?

3.     Ask the vendor to provide certification or accreditation info.

a.     SOC2 certified companies can share their certificate as proof

Secure Development  

The online world today is both a wonderful and scary place. The Internet has brought the world closer, given voice to millions, and enabled or accelerated many new methods of commerce. But, in all this good is an element of bad – corruption, fraud, mischief, and more – that we cannot ignore. Having a presence on the Internet today requires vigilance.

Developing systems and software to run online requires a modern approach to security. If your business builds custom software, be sure to utilize all the resources available – such as CISA’s new whitepaper. If your business uses software critical to your mission, hold the vendor accountable to be secure – both by-design and by-default.

 Do you want to talk more about how to ensure cybersecurity best practices are built into your business? Give us a call. We love to help!

About The Author:

Bart Holzer recently joined Affinity Technology Partners as fractional Chief Information Security Officer (CISO). He is the owner of Overt Channel, LLC, working as a fractional or virtual Chief Security Officer and Chief Information Security Officer for mid-size firms and nonprofits. A former federal law enforcement engineer, Holzer advises clients on security strategy, risk management, security program development and incident response.