Schneier on Security

Nick P • January 21, 2013 1:39 PM

@ martinr

Let me take a stab at this tangent.

“You don’t seem to have ever encountered high quality code from a skilled programmer.”

It’s so rare it almost proves his point for him. Even the Linux kernel, with it’s low defect count, comes with vulnerabilities. The majority of code seems to fare far worse. The coding should also be done in a way that an assurance argument can be made for it. Most code isn’t. Things can get better. Microsoft’s SDL, for example, dramatically improved the security of their new software. It was also too expensive for most companies to adopt.

It’s good that you mention Fagan inspections. I’ve promoted that old technique many times on this blog. Cleanroom improved on it in areas of maintenance, predictability, and certified bug counts for warrantied code. Also interesting that developers never run their own code, yet it usually works. TSP/PSP, Predictable by Construction and Praxis’s Correct by Construction are all proven to greatly improve quality with empirical methods. More methods or successes appear each day.

The problem I see with your arguments is that you mix quality and security. They’re NOT the same thing. Certain quality issues do lead to security issues. Methodologies that reduce those quality issues will reduce security issues. You and I are on the same page on that part: high quality code makes software more resistant to attack. Of course, if that’s what it took for “secure” software, then the Orange Book would have said: this system must use Fagan inspection with the correct set of “defect” classification and proven use of it. It actually required a little more….

The essence of security is that unauthorized behavior won’t occur. That implies the system will always be in one of a known set of acceptable states. Security issues happen at levels from hardware to the app itself. One must also factor in risks such as malicious developers, repository control, distribution, initialization, configuration, and maintenance of secure state. You can be the best coder in the world. However, if you get any of the rest wrong the code quality will simply be something the attacker enjoys observing as he toys with his new machine. 😉

Here’s an old (start) to trustworthy software I wrote on this blog that was mainly focused on preventing subversion. I left out a few steps at the end to make it pertain to this conversation more.

“1. Requirements for a deliverable must be unambiguous and formal.
2. Every high-level design element must correspond to one or more requirements and this should be shown in documentation.
3. The security policy must be unambiguous, compatible with requirements, and be embedded in the design/implementation. Correspondence must be shown.
4. The Low Level implementation modules must correspond with high level design elements, at least one each.
5. The source code must implement the low level design with provably low defect process and avoid risky constructs/libraries.
6. The object code must be shown to correspond to the source code and no security-critical functionality lost during optimizations.
(DO-178B Level A requires this & there are tools to help.)
7. At least one trustworthy, independent evaluator must evaluate the claims and sign the source code to detect later modifications by the developers or repository compromise. This should also be done for updates.”

This was just the software. The TCB it runs on and all libraries it trusts must be secure. If they aren’t, they must be isolated from main application in a way that contains failures. That’s hard. The app must be securely configured, sanitize all input, use easily parsed protocols/storage, exist in predefined states, preferrably be written in a safe language, and have fail-safe crash strategy for unforseen errors with logging.

The high assurance security evaluations often required more. They wanted mathematical specification of requirements, security claims and design. The highest assurance systems wanted mathematical proof of security, correctness, and/or general assurance argument. They required loop-free layering (rare today), modularity (in style), strong focus on interfaces (in style), easily analysed implementaiton constructs (uncommon), extensive testing (in style), pen testing by pro attackers (uncommon to rare today), covert storage/timing channel mitigation (almost nonexistant, although attacks exist), repo software (in style for good dev’s), physical security of repo+artifacts (uncommon), and independent evaluation of all of this by trusted, qualified 3rd party (almost non-existent).

Note that this was security in the Orange Book days. This was what it took to call a software+system combination secure on what were basically time-sharing machines, dumb terminals, and simplified desktops/networks. Things have gotten more complicated and risky since then, although issues are similar. A few follow…

1. Hardware
   a. Attacks on Intel SMM
   b. Attacks on TXT
   c. Malware in wild using processor errata (per Kaspersky)
   d. DNS subverted because software ignored cosmic ray bit flips
   e. DMA hardware (firewire attack)
   f. Overprivileged or hard to control hardware (e.g. USB HID)
   g. Perhipherals’ firmware is programmable and easier to attack
2. Mainstream Operating Systems
   a. Huge amounts of kernel code. Kernel bugs followed.
   b. Huge amounts of trusted code that modifies OS state.
   c. So bloated that ports to embedded devices are bragworthy.
   d. Quality increased for many over time, but still tons of vulnerabilities.
   e. Still plenty of issues with interfaces and legacy libraries.
   f. They almost totally ignore covert channels.
3. Middleware
   a. Middleware quality varies considerably.
   b. Documentation and actual behavior are often inconsistent.
   c. Many famous middleware are unnecessarily complicated.
   d. Combining secure code with insecure middleware often= insecure app
4. Protocols
   a. Technically a form of middleware, but I give special treatment.
   b. Most common protocols designed pre-WWW and have inherent problems.
   c. Many companies ignore superior alternatives to preserve legacy.
   d. Hardcoded protocols eventually have issues and can’t be replaced.
   e. Complex protocols are hard to implement, yet used anyway.
   f. Many attempts at secure protocols are subject to fall-back attacks.

5. Subversion
   a. Malicious developer allows compromise via clever, small change
   (See Myer’s on NFS subversion; obfuscated C contest; easter eggs)
   b. App compromised during build process.
   c. App compromised between user and developers.
   c1. Binary modified after build.
   c2. Modified during transmission.
   c3. Search results lead to backdoored versions.
   d. App compromised during installation by misconfig or malice.
   e. TCB compromised, then malware subverts app.
   f. Interactions of various software used to compromise one of them.

This is not a 100% comprehensive post on the issues. I’ve left out the most esoteric stuff like EMSEC. However, making a secure application involves ensuring the elimination of vulnerability across the entire lifecycle. It’s not as easy as a Fagan inspection or a brilliant coder. The more effective assurance arguments require a great deal of specialised expertise, time, and money. There are also many tradeoffs that one must make. The quote below gets to the bottom of why.

“If you look for a one-word synopsis of computer design philosophy, it was and is SHARING. In the security realm, the one word synopsis is SEPARATION: keeping the bad guys away from the good guys stuff. [important part] So today, making a computer secure requires imposing a “separation paradigm” on top of an architecture built to share. That is tough! Even when partly successful, the residual problem is going to be covert channels.”
-We Need Assurance, Brian Snow, NSA Technical Director

Old guard tried for decades to build secure systems/software. Certain simple, somewhat specialized systems went unbroken and seem secure. Others were just very hard to attack, limited damage and recovered well. Old principles strained due to issues like DMA and inherent difficulty of securing networked/web environment. The end result, which I promote, is that we can use proven methods to increase quality and assurance of software. We can’t claim the software is “absolutely secure,” as Clive noted. Anyone claiming an impenetrable or bug-free offering should be looked upon with great skepticism.

However, increasing assurance across the board eliminates the low hanging fruit current malware authors enjoy, stops the majority of attackers, reduces overall losses, and helps to gradually reduce everyone’s overall risk over time. Certain companies are taking the lead and producing very robust software. I hope more follow.