Requirement #1: Secure the Deployment
An observation that spread through the recent Black Hat 2016 and DEF CON 24 conferences about Windows 10 is that it’s quite robust from a cyber-defense perspective—until you start installing application software on it. That’s like saying an airplane is really safe—until you put passengers on it.
The point is, no one should congratulate themselves on fielding a system that’s secure and reliable in a laboratory, but not in real-world conditions. A barebones computer without application software installed is useless. Indeed, Windows is ubiquitous—and therefore a high-profile target for hackers—because of its application software ecosystem.
Software Security Checklist
The good news is that the raw materials for implementing secure PC software, whether server-side or client-side, are available, and all of the tools are free. Here’s a checklist of the most readily accessible:
- No banned APIs
- Stack cookie
- Data Execution Prevention (DEP) (This must be enabled during the compilation of all application binaries.)
- Address Space Layout Randomization (ASLR)
- Heap protections are generally enabled by default and tend to improve with each compiler and operating system release. Heap protections are a good example of why it’s important to upgrade your own systems in addition to keeping pressure on your vendors.
- Latest runtime versions, third-party packages, and libraries
- Keeping systems fully patched and up to date is a chore, and third-party software only makes the chore harder. And essentially all software is built using third-party libraries. Thus, not only do you have to keep your computers up to date, you depend on your vendors to get timely updates from their vendors.
- Some per-vendor historical security vulnerability data is available via the National Vulnerability Database (NVD), but it’s important to note that (a) the NVD is always at least several months behind and (b) not all issues get publicly disclosed.
- Safe-Structured Exception Handlers
- Security Development Lifecycle (SDL)
- There is compelling evidence that rigorous SDL processes improve software quality. However, it’s unknown whether security-specific SDL processes result in fewer security bugs. Since the likely outcome of a mature SDL is fewer bugs overall, it’s likely there will also be fewer security bugs.
- The onus must be on the vendor to provide documentation (or artifacts, in the parlance of compliance auditors) of their SDL processes. Based on the Application and Infrastructure Security consulting experience of JW Secure, the single most compelling piece of SDL documentation is a well-written, up-to-date threat model report. A threat model, in and of itself, does not constitute an SDL, but its availability and quality are positive indicators.
- 64-bit versions (Using 64-bit software on 64-bit operating systems—which includes almost all new Windows and Linux systems—offers some security benefits.)
Are we there yet?
You may be asking yourself (or your IT software development team and vendors), why haven’t all these protections already been implemented? It’s important to keep in mind that all software and business process changes incur a cost. Security is a moving target and even though pursuing that goal may be critical to the longevity of your business, it isn’t free.
Any changes to a software application, even if it’s just for a recompile using the latest tools, requires engaging several distinct personnel roles, including program management (for justification and prioritization), developer, tester, release management, and IT operations. Depending on licensing and support models, there can be a perverse disincentive (including from the customer’s perspective) to accept any changes, even those that make demonstrable improvements to the value of the software.
Do you need motivation?
So why bother pushing for security improvements? Why keep the pressure on? Because security bugs are exploitable. It’s just a question of motivation (and opportunity) on the part of the attacker. Some examples of the inventiveness of attackers include:
- Remote attacks against air-gapped networks
- Using static analysis to determine ease of exploitability
- Bug bounties
- Drone-based cyber-attacks
Trust, but verify
You must probe the reputation and credibility of your software vendors to know how much faith to put in the security of the software they provide. Ignorance is not bliss. If your questions are met with blank stares or silence, assume the worst: Your software is not secure, and you must fence those systems with additional protection. Plus, you’d better try to find a more credible vendor.
How can you gather your own data about the security of the software in your environment? Two useful tools for Windows are Process Monitor and Attack Surface Analyzer from Microsoft. For a broader discussion of configuration change management tools, including for Linux, see How to record server changes?