Secure by default is not a new issue, but it is an ever-increasing challenge. That’s because enterprise environments continue to become more complex as IT capabilities increase and the sheer volume of data grows exponentially. Technology stacks have many moving parts, with a lot of unique dependencies and requirements.

In this world, the traditional view of secure by default — which has largely been secure out of the box — is too narrow. Instead, secure by default today is no less than an entire ecosystem of moving parts aligned to the same goal. In fact, it is not really possible to build a product that’s secure out of the box. For secure by default to truly reach its potential, customers who use that product must be able to securely develop and deploy solutions for it.

To broaden a view of secure by default, consider these three parameters:

1. How you build it: Products and applications need to be built with security in mind — from the beginning. This means best practices and rigorous processes need to be followed. For instance, penetration testing can mimic real-world attacks that circumvent security controls. Threat modeling can model IT systems and software to understand potential threats, categorize possible impact, and then mitigate vulnerabilities. Code reviews ensure use of current versions of standard libraries and appropriate cryptography. Developers need to understand secure coding and adhere to coding best practices.

2. How and what you do when you install it: Once a product is built to be secure by default, it still needs to remain that way once deployed in its environment, which is increasingly complex and interconnected. That’s why the first responder — the person installing the product, application, or database — is evermore important. To keep the organization and users safe, the first responder needs to apply general principles, such as configuring controls to be secure as possible, enabling encryption at rest and SSL/TLS secure communication channels, restricting access to applications or data only to those people who need it, and requiring authentication that relies on trusted identity sources. Certificate or key-based authentication also are considerations.

General principles can guide administrators, yet one size does not fit all. Administrators also have to tailor approaches to specific environments. What banks need from their databases, applications, and other technologies, for instance, is different from what oil companies or intelligence agencies need. Whatever the industry, someone needs to watch the whole picture. For instance, a database sits between an application above it and an operating system below it. A network brings them all together. Each one of those layers has to do something appropriate for that layer in terms of security. But if one layer is not secure, there’s potential for a failure of the weakest link to compromise the entire system.

Another test of secure by default at the installation level is whether the end user needs specific technical understanding to securely use an application or database. If he does, the administrator has more work to do.

3. What policies and governance are set up: Data management policies need to be continually enforced to protect an enterprise’s most valuable asset: its data. These policies govern data and validate data provenance, where the data came from, as well as when, how, and if it was changed, and by whom. Data policies also need to follow the data, no matter where it goes. This will ensure that safeguards such as encryption and access controls remain in place.

Separation of duties is also key. The system administrator, who controls the server, should not have access to the database, while the database person should not have access to security controls, and vice versa. By having a separation of duties, no one role can compromise the system.

Throughout the Enterprise
Secure by default still means having the best security possible without users even knowing that it is there. But the pace of data breaches continues to indicate that enterprises have a long way to go to achieve secure by default throughout their ecosystems of technologies.

By broadening the view of what secure by default entails, enterprises will be more likely to build systems that are secure top to bottom. This requires involving humans even more in the oversight and administration to make sure that secure by default extends throughout the enterprise.

After all, when it comes to security, the old adage is really true: You are only as strong as your weakest link.

Related Content:

Why Cybercriminals Attack: A DARK READING VIRTUAL EVENT Wednesday, June 27. Industry experts will offer a range of information and insight on who the bad guys are – and why they might be targeting your enterprise. Go here for more information on this free event.