Cloud

6/26/2018
10:30 AM
Tom Thomassen
Tom Thomassen
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Secure by Default Is Not What You Think

The traditional view of secure by default - which has largely been secure out of the box - is too narrow. To broaden your view, consider these three parameters.

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.

Tom Thomassen is a senior staff engineer of security at MarkLogic. He is responsible for helping identify and implement secure development practices into the company engineering process, educating the team on security best practices, monitoring and responding to changes in ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
New Cold Boot Attack Gives Hackers the Keys to PCs, Macs
Kelly Sheridan, Staff Editor, Dark Reading,  9/13/2018
Yahoo Class-Action Suits Set for Settlement
Dark Reading Staff 9/17/2018
RDP Ports Prove Hot Commodities on the Dark Web
Kelly Sheridan, Staff Editor, Dark Reading,  9/17/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
How Data Breaches Affect the Enterprise
How Data Breaches Affect the Enterprise
This report, offers new data on the frequency of data breaches, the losses they cause, and the steps that organizations are taking to prevent them in the future. Read the report today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-17182
PUBLISHED: 2018-09-19
An issue was discovered in the Linux kernel through 4.18.8. The vmacache_flush_all function in mm/vmacache.c mishandles sequence number overflows. An attacker can trigger a use-after-free (and possibly gain privileges) via certain thread creation, map, unmap, invalidation, and dereference operations...
CVE-2018-17144
PUBLISHED: 2018-09-19
Bitcoin Core 0.14.x before 0.14.3, 0.15.x before 0.15.2, and 0.16.x before 0.16.3 and Bitcoin Knots 0.14.x through 0.16.x before 0.16.3 allow a remote denial of service (application crash) exploitable by miners via duplicate input. An attacker can make bitcoind or Bitcoin-Qt crash.
CVE-2017-3912
PUBLISHED: 2018-09-18
Bypassing password security vulnerability in McAfee Application and Change Control (MACC) 7.0.1 and 6.2.0 allows authenticated users to perform arbitrary command execution via a command-line utility.
CVE-2018-6690
PUBLISHED: 2018-09-18
Accessing, modifying, or executing executable files vulnerability in Microsoft Windows client in McAfee Application and Change Control (MACC) 8.0.0 Hotfix 4 and earlier allows authenticated users to execute arbitrary code via file transfer from external system.
CVE-2018-6693
PUBLISHED: 2018-09-18
An unprivileged user can delete arbitrary files on a Linux system running ENSLTP 10.5.1, 10.5.0, and 10.2.3 Hotfix 1246778 and earlier. By exploiting a time of check to time of use (TOCTOU) race condition during a specific scanning sequence, the unprivileged user is able to perform a privilege escal...