Security Adviser | Roger A. Grimes » February 2008

February 29, 2008 | Comments: (0)

Security Development Lifecycle trumps code complexity

TAGS: Application Development

In last week's column, I talked to Bruce Schneier about complexity, one of the main reasons it will be hard for computer security to improve in the future. As software becomes more complex, in terms of more lines of code or functionality, the harder it becomes to stay secure. More lines of code mean the potential for more security bugs. Increasing feature sets means more opportunities for programs to be used and manipulated in unexpected, malicious ways. In general, I wholly believe in this axiom, but it doesn't always have to be true. In fact, there is empirical evidence that better coding practices can more than offset the complexity argument.

Michael Howard is the co-author of several books on Security Development Lifecycle (SDL), and he's principal security program manager at Microsoft. (Full disclosure: I am a full-time employee of Microsoft.) He, like myself and thousands of Microsoft security employees, cares more about computer security than allegiance to the company. We call a spade a spade, even when it doesn't always reflect well on Microsoft. Luckily for us, security is a top concern at Microsoft, despite what some people will tell you. It may not be the only decision point, as it is for OpenBSD, but it is as important as any other initiative the company has, if not more.

Michael is heavily involved in Microsoft's use of SDL in its own software. And the results of SDL has meant fewer found vulnerabilities in SDL-developed software in the same time periods as compared to pre-SDL software versions. Michael's article starts first by referencing Jeff Jones' blog entry comparing Windows Vista vulnerabilities to those of Windows XP and other first-year OS releases.

There is no doubt that the number of vulnerabilities in Microsoft's software is going down despite increasing complexity. Critics, including some who are sure to write heated e-mails in response to this column, constantly blast Jeff Jones' figures. I don't know why -- he uses industry-accepted figures, grabs his numbers from external, independent sources, and compares apples to apples in terms of default software and feature sets.

Some critics say that a single metric neither means everything nor tells the whole story. I agree. What I won't accept is that it doesn't mean anything. I don't care how much you hate Microsoft, and the record still needs lots of improvement, but the number of found vulnerabilities is going down, year after year. SDL is working.

Microsoft SQL 2000 had 10 vulnerabilities, the last in early 2004; Microsoft SQL 2005 has had none. Internet Information Services (IIS 5) had 12 vulnerabilities; IIS 6, released in March 2003, has had five.

Even in the most heavily attacked Microsoft products, with high found vulnerability counts, the overall trend is positive. In 2003, Internet Explorer 6 had 24 vulnerabilities versus Internet Explorer 7's 17 in 2007. IE is tracking nearly dead even with Mozilla's Firefox 2.0, built as the "secure alternative" browser. It might not surprise you to learn that Window Snyder, Mozilla's CSO, is a heavy promoter of SDL.

All of these statistics are not just to inflame anti-Microsoft zealots, but to promote two points.

First, although complexity is the enemy of security, increasing complexity doesn't always mean more vulnerabilities. If your software security coding practices are nonexistent or hugely inconsistent, SDL practices can offset the increasing complexity problem, at least for your product. Increasingly complexity may still make the Internet an unsafe place, because a gazillion new products and protocols are being invented every day, but less because of your product.

Second, if you're a developer and your company is not using SDL, it's time to get on it. There are books on it everywhere. You can search on titles by Michael Howard or look for other books on writing secure code and/or threat modeling.

If you want to improve your company's security programming, teach SDL and build it into the company culture. It might take a little while to get the ship turned around, but once you do, the results are tangible, and they'll benefit everyone.

And contrary to popular belief, Microsoft wants all companies, even tough competitors and open source advocates, to write more secure code. More secure programs make a more secure Internet, which benefits everyone and every platform.

A rising tide lifts all boats.

Posted by Roger Grimes on February 29, 2008 03:00 AM

February 15, 2008 | Comments: (0)

Is your Web site FIPS compliant?

TAGS: FIPS

FIPS compliance can be the key to working smoothly with servers and clients both in and out of government service

I've been involved in a lot of FIPS-compliance Web site testing lately. I'm a crypto hobbyist, not a crypto expert, so I hesitate to write about it, but I'll explain the basics as well as I understand them. Crypto experts, please write in if I messed up something important.

FIPS stands for the Federal Information Processing Standard, essentially a series of standards and mandates for U.S. government agencies and supporting contractors. In many cases, if your product or service is not FIPS compliant/certified, the government can't use it. The FIPS documents are so respected that many other countries mandate them as well or have incorporated the bulk of their guidance into international standards.

There are many FIPS mandates, but the public pronouncements most Web site administrators care about is FIPS 140, which approves various cryptographic ciphers for hashing, signature, key exchange, and encryption purposes. FIPS 140-1 was approved in January 1994 and included the 64-/56-bit Data Encryption Standard (DES), which has since been removed as supported cipher. FIPS 140-2 was released in May 2001 and includes all the current approved ciphers, including the ones listed below:

Symmetric ciphers
AES
3DES
Skipjack/KEA (EES)

Asymmetric Key-Signature
DSA
RSA
ECDSA
MAC
3DES

Hashes
SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512

(Taken from "Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules")

It surprises many people to learn that Triple-DES (3DES) is still FIPS compliant; it is and will be for many more years. FIPS 140-3, the latest version, is currently under review and should be approved in 2009. Windows XP (RTM to SP2) is FIPS 140-1 certified. Windows Server 2003 and later, Vista, and Windows Server 2008, are FIPS 140-2 certified. The original ciphers supported in Windows XP were grandfathered to FIPS 140-2. A few ciphers were added or updated in Windows XP SP3, so XP SP3 has to be recertified, even though the ciphers are the same ones approved in Vista and Windows Server 2008. You can read the current status of any FIPS-certified product by going to this Web site; just search on your vendor's name.

Additionally, the National Security Agency is pushing a new cipher requirement standard known as Suite B. It calls for many FIPS 140-2 ciphers, but it adds a few of its own (such as Elliptical Curve Cryptography) and specifies minimum key sizes. Windows Vista and Windows Server 2008 and later support Suite B ciphers. I'm not sure what distributions of Linux and other operating systems support Suite B, but it can be inquired of each OS vendor.

Certified and compliant
There is a common confusion point between FIPS certified and FIPS compliant. Clients frequently tell me that their Web site or database application has to be FIPS certified, but what they really mean is that it needs to be FIPS compliant. FIPS certification is a laborious, long, and expensive process, where a crypto vendor submits its product to a FIPS certification lab to obtain a FIPS certification certificate. Most noncrypto vendors are expected to be FIPS compliant, which means they use and rely on other FIPS-certified products for their solution. But there is a big, costly difference between the two options.

Many security standards, including the new Federal Desktop Core Configuration requirement, insist that participating computers be FIPS compliant. For Windows, this means enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" group policy setting, which can be done in Windows XP and later. This enforces the use of FIPS-compliant ciphers, including to SSL/TLS-protected Web sites. FIPS compliancy is supported in most current BSD, Linux, Unix, Mac, and Solaris distributions, as well as the popular OpenSSL software component.

FIPS-enabled computers can only connect to Web sites with FIPS-compliant ciphers for SSL/TLS. Windows servers running IIS should also have the aforementioned FIPS group policy setting enabled, along with the appropriate digital certificates and ciphers. Unfortunately, anyone who has had to implement FIPS-compliant workstations knows that many popular Web sites are not FIPS compliant. In order for your Web server to be FIPS compliant, it needs to work with at least one cipher SSL/TLS mechanism that supports contiguous FIPS-compliant ciphers for signing, hashing, and encryption (such as RSA_3DES_SHA1). For instance, if your Web server only has ciphers involving DES, RC4, or MD5, it's likely that it isn't FIPS compliant.

SSLDigger, a free tool by Foundstone, is great at interrogating Web servers and revealing which ciphers the Web server does or doesn't support. This is the tool to run if you're in charge of making sure your Web site(s) are FIPS compliant or if you're troubleshooting an FIPS-compliant browser that's throwing a cipher error against a particular site. Unfortunately, it's got a few bugs and doesn't work through proxies.

Once SSLDigger has given you a list of the ciphers a Web server supports, you can compare it against the list of FIPS-accepted ciphers or against Microsoft's FIPS-implemented ciphers.

If both the Web site and the client are FIPS compliant and you're still having issues, a proxy device or firewall could be causing the problems. Often, intervening devices prematurely (on purpose) terminate the HTTPS connection and substitute their own noncompliant ciphers in place of the otherwise compliant end points. It will drive you crazy if you're not expecting it as a troubleshooting point.

If Web sites fall under your control, make sure they are FIPS compliant, or soon tens of millions of customers will not be able to access them.

Whew, there you have it. FIPS servants, go forth and multiply!

Posted by Roger Grimes on February 15, 2008 12:23 PM

February 08, 2008 | Comments: (0)

Computer security: Why have least privilege?

TAGS: Least privilege

Least privilege won't solve every security problem, but it's a significant step in the right direction

My previous column on the questionable long-term effects of least privilege created a firestorm of controversy and discussion. Personally, I think controversy is good if it gives people on both sides of the argument a chance to reconsider their previous conclusions. If the argument changes your mind, then maybe your original conclusions needed more consideration. And if it strengthens your support, one way or the other, then at least you had an opportunity to reexamine your beliefs and provide yourself even stronger arguments.

What I wasn't prepared for was how many people thought I hated Microsoft's User Account Control (UAC), or thought I disagreed with the concept of least privilege. Both these arguments couldn't be further from the truth. There are lots of reasons to use least privilege mechanisms, UAC or otherwise. Off the top of my head, here are four:

First and foremost, least privilege models prevent 90 percent or more of today's malware. You can't ignore that statistic. Malware writers may easily code around least privilege when they need to, but it does significantly cut down on software that can cause harm today.

Second, least privilege mechanisms make it harder for malware to modify key system components. While malware may be able to still do harm -- much harm -- with user-mode programming alone, not being able to semi-permanently modify the operating system does provide protection you would not have otherwise.

This makes it more difficult for malware to hide from anti-malware software and forensic investigators. Malware with system access can install itself as a rootkit, more easily hide in memory, or perform myriad other obfuscation techniques that make it more difficult for the good guys.

Third, if your end-users don't have administrative access to their machines, you can prevent them from installing unapproved software. Since the vast majority of today's malware relies upon the end-user installing or clicking on something they shouldn't, as well as having admin or root access, not having it will prevent attacks.

Limits are good
Least privilege (such as UAC, su, and so on) is a good thing. Using it can only improve security measurably. The key takeaway point of the previous related column is that least privilege mechanisms are part of a defense-in-depth puzzle, but surely not the endgame.

Not to start up another firestorm of controversy, but it's the same issue with firewalls. Sure, a properly configured firewall can prevent all sorts of network-connecting, dial-home, blast-the-Internet-and-attack-other-people malware -- well, all the malware that doesn't use ports 80 and 443.

Nearly all computers and networks allow port 80 and 443 communication to flow from trusted computers onto the Internet, and the related response traffic to come back in. If malware wants to be more successful, aside from other port-specific buffer overflows (for example, the MS-Blaster worm on RPC port 135), it should always use port 443. Why? First, it's always open and allowed out onto the Internet, and 99 percent of companies have no way to monitor SSL/TLS encrypted traffic over port 443. The malware can use Internet encryption standards to bypass detection. I'll go further: Any network-connecting malware not using port 443 to dial home and spread is unintelligent software.

When every network and computer in the world closes down every unauthorized port, it won't stop malware. Malware writers require only one guaranteed-to-be-open port to do everything they need.

Least privilege log-on models are great and necessary, but they aren't fail-safe security defenses. Ultimately, the malware writers will easily write around them and continue doing all the mischief they want.

The fourth reason for least privilege
But the fourth reason why least privilege mechanisms are desirable and necessary is that they allow defenders to concentrate their efforts on better protecting fewer ingress points. For example, suppose you have a castle with four entry points over the surrounding moat. When you have that many entry points, you have to provide equal protection (from soldiers, hot tar, flaming arrows, and more) to all four of them; otherwise, the attacker will learn the weakest point and attack it first. By reducing the number of entry points, the defensive force can spend less money overall and better protect what remains. The same goes for least privilege computer defenses.

Posted by Roger Grimes on February 8, 2008 01:54 PM

February 01, 2008 | Comments: (0)

Strategic security: Get a handle on authentication

TAGS: Authentication

One rational, standardized authentication policy across the organization will make all your applications more secure

It's a common dilemma: You host multiple Web-accessible applications, for both internal customers and external users. A few of your developers are keeping up on the last programming trends and security models, while some of your highest-seniority employees are stuck in programming models outdated a decade ago. You've got a hodgepodge of access and authentication methods, along with a lot of client-server interaction, and a little bit of Web services and SOA, as well as Citrix or Terminal Services thrown in. There are even a few people still dialing in on phone lines to access dumb terminal-based applications.

Truth be told, if someone asked what you thought of the situation, you'd reply it's a deck of cards just waiting to be pushed over by the right inquisitive hacker. You've got to get control of your applications and authentication models, so where do you start and what do you do? There are six broad areas that you'll need to address: education, strategy, standardization, policies, remediation, and retirement.

Education
The first step is to educate everyone about the problem. Many of your coworkers and members of management may not be aware of your dilemma. Sure, you've groaned about it here and there, but it hasn't become a top-level concern. It isn't even on the list of things your boss is worried about. It's time to elevate the issue. Develop a cohesive, thoughtful paper on the current situation, the problem, and steps toward a solution, then present it to your supervisor. Do it out of the blue, and you'll even score points with the boss.

The second step is to educate people about the various authentication components. Essentially, you want to explain identity, authentication, authorization, and access control (and accounting/auditing), or simply AAA, as parts of a systematic process, each of which can be accomplished using various methods.

And you want to push for more maturity on each of those concepts. If single users end up with multiple identities, you need an identity management system (or maybe federated identities, if multiple companies are involved). You want to move authentication from passwords to something more sophisticated, such as two-factor authentication. You want to move access control from Discretionary Access Controls (DAC) to client-server impersonation and eventually Role-Based Access Control (RBAC).

Finally, the data you protect must be categorized according to sensitivity and protected accordingly. The idea is to get staff and management thinking about the process, or processes, in a strategic manner -- to move away from individual silo thinking.

Strategy
Once the boss realizes there's a real problem, it's time to create an overall guiding strategy. Say something like, "Decrease overall computer costs and security risk by designing strong data controls." (Wow, that almost hurt to think of, drawing back on my Dilbert-like days in management, where you have to say almost nothing to accomplish something.)

The idea is to make the problem a strategy. Your boss and your boss' boss can't act until you've developed a strategy and, more than likely, tied that strategy to existing business objectives. From the strategy, build tactical methods to accomplish it.

Standardization
Standardization needs to be part of everyone's authentication strategy. It's the wide variety of authentication methods employed that got the company into this trouble in the first place. Identify all the current methods, and include a few that seem viable for the next 5 to 10 years. Then pick the ones that the company will officially support as standard(s). If you can't standardize, you'll never get out of the hole you're in. Of course, I guess your standard could be that you'll support anything that anyone wants. In that case, better you than me.

Policies
Come up with the tactical components and write policies to support them. It might be something like, "All future custom programming will use Web services, SOA, and role-based access control. All incoming access will end at a proxy firewall where authentication, traffic normalization, and scanning will take place, then the request will be reverse-proxied to the intended end point." Or maybe you, like several companies I know, will decide to do away with the DMZ concept altogether. Use a group to create the policies to support the overall strategy, and get it approved by management.

Remediation
Next, fix the highest-risk assets first, followed by applications with lower use and exposure. This means fixing existing systems, implementing the new policies in new custom projects, and enforcing the new policies when buying new software.

Retirement
If a legacy application cannot be brought in line with the new policies, consider getting rid of it. Give end-users a reasonable period of time to select and implement a new system. If the system will not be replaced and you can't adequately protect it using the new policies, communicate as much to management so that they can make the final risk decision.

Even if you can't help your company work through all of these steps, you've improved security and lowered risk just by getting your colleagues, employees, and management to think about AAA in a strategic way. At least it will be on the radar as a consideration, versus the growing deck of cards that keeps you up at night.

Posted by Roger Grimes on February 1, 2008 01:59 PM