Steve Riley on Security : risk mitigation

Poll: do you use scheduled scans for malware?

Steve Riley — Mon, 05 Jan 2009 23:03:59 GMT

An interesting comment recently appeared on my older post about whether or not to use antimalware software. Peter van Dam wondered whether scheduled scans are really necessary, given that anti-malware products scan files as they enter (and sometimes exit) a computer.

He raises a good point, and I’m curious what all of you think? Do you use scheduled scans? If so, why? If not, is it because you’ve decided the same as Peter?

Updated Microsoft Security Assessment Tool

Steve Riley — Tue, 02 Dec 2008 07:13:03 GMT

Greetings. In case you haven’t already read about it, we recently updated the Microsoft Security Assessment Tool (MSAT). Version 4.0 hit the web on 31 October. It’s been four years since the initial release, and two years since the prior version. Between then and now your security world has evolved a lot, and the tool now reflects that.

Download now: http://www.microsoft.com/downloads/details.aspx?FamilyId=CD057D9D-86B9-4E35-9733-7ACB0B2A3CA1&displaylang=en

Take a few moments and give yourself a security checkup. If you have any comments or feedback on the tool, feel free to leave them here on my blog—I’ll make sure the right people see it.

Update: got an email from someone with two questions:

When you install the tool, the UAC dialog shows “Microsoft Corporation (Internal Use Only).” This is the CA that signed the tool, and it’s an internal CA—thus the “internal use only” bit.
The tool fails to run on Vista x64. This is a known issue, we’re working to fix it.

From the download page:

The MSAT employs a holistic approach to measuring your security posture by covering topics across people, process, and technology. Findings are coupled with prescriptive guidance and recommended mitigation efforts, including links to more information for additional industry guidance. These resources may assist you in keeping you aware of specific tools and methods that can help change the security posture of your IT environment.

There are two assessments that define the Microsoft Security Assessment Tool:

Business Risk Profile Assessment
Defense in Depth Assessment (UPDATED)

The questions identified in the survey portion of the tool and the associated answers are derived from commonly accepted best practices around security, both general and specific. The questions and the recommendations that the tool offers are based on standards such as ISO 17799 and NIST-800.x, as well as recommendations and prescriptive guidance from Microsoft’s Trustworthy Computing Group and additional security resources valued in the industry.

After completing an Assessment, you will gain access to a detailed report of your results. You may also compare your results with those of your peers (by industry and company size), provided that you upload your results anonymously to the secure MSAT Web server. When you upload your data the application will simultaneously retrieve the most recent data available. To be able to provide this comparative data, we need customers such as you to upload their information. All information is kept strictly confidential and no personally identifiable information whatsoever will be sent.

Who should do your security audits? Or, how do you organize the security department?

Steve Riley — Fri, 08 Feb 2008 01:25:32 GMT

An interesting question came up today. The group responsible for configuring and maintaining the firewalls at a customer also believes that they should be the only ones to audit their configurations. Others in the security department are uneasy with this, and prefer that someone else do the auditing. I've encountered similar tension before, and it always makes me wonder why information security folk and auditors frequently have trouble working together. As I thought more about this, I began to wonder if maybe there's a better way to organize the entire security department.

It's useful if we take a moment and consider the definition of the auditing function. Here's mine:

Audits help us ensure that we are following our own policies. Audits measure the current state, compare the results against what the state should be, and show where we are out of compliance. Essentially, audits help us know that we are indeed doing what we say we're doing.

Audits are the natural outcomes of implementing good policies and following effective procedures. It makes no sense to spend time developing policies and without having some mechanism to measure compliance. That's the role of the auditing function -- to measure compliance. If we all agree that policies are good, then we should all agree that checking up on ourselves is also good.

So, then, who should conduct the audits? For comparison, let's examine a typical software development department. Here at Microsoft, such departments are composed of four over-arching roles:

program management
product management
software development
software test

Why this way? Consider the first two. We don't have "project managers" at Microsoft because project management incorporates two conflicting goals: managing people, schedules, and budgets (program management) versus incorporating customer requirements and creating new markets (product management). Program management optimizes resources while product management optimizes features. Rather than shoulder that inherent conflict onto a single person and expect them to deal with it without going completely bonkers, we have two roles, with different people. People skilled in each area negotiate with each other and come to an agreement about what's best both for Microsoft and for our customers.

Similar thinking exists for the second pair of roles. Developers strive to write high-quality code, and even do some testing along the way. But because no one's perfect, all code has some mistakes; it's valuable to have other people bang hard on the code, abuse it almost, to find and squash more bugs. Often, even the best developers are embedded so deeply in their own code that some bugs escape them. Developers rightly concern themselves with creating code that works and provides proper output. Testers figure out how to purposefully break software and discover code vulnerabilities. These are different skill sets, and using different people results in higher quality software.

We can apply the same logic to the information security department. How about these four roles:

security standards
security alignment
security operations
security auditing

The security standards group defines an organization's security architecture, creates policies and procedures, and ultimately takes responsibility for stewarding the integrity of the organization's information assets. The security alignment group spends time understanding the needs and drivers of the various business units, and advocates the business units' positions in meetings with the security standards group. Like in the software development model, having different folks negotiate together about standards and alignment helps ensure that business needs are met while also ensuring that the business is able to rely on information that's kept secure.

Remember: the primary purpose of information security is risk management. The standards folk know all about the bad guys and their techniques, and build up knowledge about which threats create risk for the organization. The alignment folk understand, through their constant interaction with people in the business units, all about business risk and get a feel for the business's risk tolerance -- that is, the level and kinds of risk that matter or don't matter. Together, the security standards and the security alignment folk can develop a security posture that allows the business to remain agile while also addressing the risks that make sense.

(Notice that I haven't indicated where, exactly, the alignment folk sit within the organization. They might be part of the security department, or they might be part of the individual business units. A case could be made for either choice; however, except for very large organizations, the alignment role probably isn't full-time. This leans the role toward sitting in the business units.)

Day-to-day work becomes the responsibility of those in security operations. They create standard configurations, perform installs and updates, monitor traffic, and respond to incidents. Ideally, policies and procedures guide all of these activities. But having policies and procedures isn't enough: we must also have a way to measure conformance. And that's the role of security auditing. Security auditors compare a system's current configuration to what it should be, based on the policy. Where systems are out of compliance, the auditor works with operations folk to understand the reasons, without engaging in blame-storming or launching personal attacks (this goes for operations folk, too). Most of the time, it's simply a mistake; here, auditors are like software testers, uncovering configuration vulnerabilities (bugs) that otherwise might be overlooked by operations and thus exploited by attackers.

Now you auditors out there, this doesn't mean that your role is simply that of checklist slave. Especially if your checklist is something you downloaded from the Internet. Remember: these checklists are only guidance, good ideas written by a person (or a committee) based on that person's risk tolerance. Effective auditors develop relationships with people in the other three groups: standards, alignment, and operations. Effective auditors take the time to learn the security landscape, how attackers operate, where vulnerabilities lie, and which threats matter. Really effective auditors learn how to do penetration testing, thus uncovering not only code and configuration vulnerabilities but also circumvention vulnerabilities through social engineering. By doing this, effective auditors remove the "us versus them" stigma often associated with auditing and truly become part of the security team, all working together to protect the organization's information assets.

(Notice that, as with the alignment group, I haven't indicated organizationally where the audit group should sit. I do, however, have a strong opinion on this: the management chains of the audit group and the operations group must be different. The people conducting audits shouldn't work for those who have a stake in an audit's outcome. To do so would create unavoidable and unrecoverable conflicts of interest.)

I'm sure there's more to the topic of organizing a security department. What do you think of this approach? Do you like the idea of dividing conflicting roles into different groups, then structuring them to work together to achieve realistic and useful outcomes? I don't suspect I've necessarily invented anything new here, but maybe just used a few new words -- such as "security alignment" -- and thought out loud about some of the tension that exists within the standards/alignment and operations/audit pairs. (Oh, and I got to write about my code/configuration/circumvention vulnerability triple again, heh.) Please tell me your thoughts. Maybe there's an entire white paper here, possibly even a TechEd presentation. Maybe someday we should offer a "TechManagementEd" conference!

More on Autorun

Steve Riley — Wed, 31 Oct 2007 01:12:27 GMT

Last month, in my post "Autorun: good for you?" I described why I believe you should disable Autorun on all computers in your organization. I also explained how you can do this for XP and Vista computers.

Well, it turns out that Windows will override this setting if you insert a USB drive that your computer has already seen. I received an email from Susan Bradley that links to an article on Nick Brown's blog, "Memory sitck worms." Nick mentions the MountPoints2 registry key, which keeps track of all USB drives your computer has ever seen. I'll admit, I didn't know this existed! I'm glad Nick wrote about it, though.

Nick also includes a little hack that effectively disables all files named "autorun.inf." Interesting, but something in me prefers to make Windows just plain forget about all the drives it's seen. So now I will amend my instructions. In addition to what I wrote earlier, you should also write a small script, and execute it through group policy, that deletes the following key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

When I searched for it in my registry, I also found a few others, so maybe you'd want something that would search through the registry and delete them all, although I don't know if such a tool exists -- I've never had a need to look for something like that.

What's your data worth? More importantly, to whom?

Steve Riley — Thu, 25 Oct 2007 09:49:21 GMT

This week, I'm attending and spoke at a cybercrime conference in Singapore. One of the presenters made a very good point, and I want to share it with you.

When considering how to protect your data, don't consider how valuable it might be to an attacker. Always, instead, consider how valuable it is to you.

I know, it seems so simple when you see it in print. But, surprisingly, many people take the opposite approach. "We don't have anything of value to anyone else, we don't need security." There's no more dangerous statement than this. Resist the urge to think about its value to the bad guys when deciding how to secure your data, because if you think your data isn't valuable to anyone else, then you'll probably get the security wrong (that is, you won't have enough).

If you've got data accessible online, it's valuable to someone -- you! Why else would you put it up? It's logical, then, that it might be valuable to someone else, even if you can't imagine how. So think about your data's value to your organization: how much is it worth, and what is your exposure if the data is stolen, compromised, or lost. When you take this approach, you'll get the security right, and your decisions will reflect the true value of your data.

More on the necessity of antivirus software

Steve Riley — Tue, 25 Sep 2007 20:53:47 GMT

A few days ago, I wrote a brief post about my non-use of antivirus software on my own computers. A number of people have asked me privately if I am recommending such a stance to other individuals or to organizations. Let me be perfectly clear: absolutely not. For the vast majority of folks, the four important steps to protect your PC still hold:

Run the Windows Firewall
Keep Windows and your applications up-to-date
Use current antivirus software
Use current antispyware

These are good recommendations for organizations, as well.

But as I've talked about many times in the past, security decisions always involve tradeoffs. They also (should) involve an intimate understanding of what the users will be doing with their computers. Fact is, most individuals who are not full-time security professionals often make mistakes when trying to decide whether something is legitimate -- witness the ongoing success of phishing and 419 scams. And organizations, unless they run highly locked-down environments, often can't know everything their users are doing.

As I said in the previous post, anti-malware is not useless. It is a necessary element in your suite of defensive technologies to help keep the bad guys at bay. In my post I'm simply explaining a personal tradeoff I've made on my own machines at home--that by not running as admin (which I didn't mention before), by using UAC, by relying on the firewall, and by training my family--I have made the decision not to use anti-malware.

So should you make the same tradeoff? Well, that depends. If you're asking me about your own use of your own personal computers at home, I can't answer that for you, you need to. Remember what I wrote: "I know what to click and what to skip, what to visit and what to avoid. I have control over what I choose to open, what I choose to load, and what I choose to run." Do you have similar self-control? :)

If you're the security administrator for an organization, you should not make this tradeoff. Again, remember what I wrote about my own self-control; I doubt that anyone could make such a statement for everyone in their organization! Antimalware definitely belongs on machines where users can store or transfer files:

client computers
email servers
file servers
SharePoint servers

The purpose of my earlier post was to spark a little discussion, to see what other opinions there might be. Some folks are doing the same thing I am, others always run anti-malware on every computer. Neither stance can be declared "right" or "wrong." It's simply a reflection that we all make tradeoffs, every day, when we decide how to manage and use our computers. And as I suspected, different folks make different tradeoffs, based on their own risk tolerance and experience. These are always good conversations to have.

Autorun: good for you?

Steve Riley — Sun, 23 Sep 2007 08:29:48 GMT

Yes, if you're a five-year-old and you're tired of always asking mom or dad how to start the game on the CD. No need to know how! Just pick up the disc (a little peanut butter on your fingers helps with the grip), slide it in the drive, and wait for the game to start. Groovy!

No, if you're a security administrator. Many people still aren't aware of the security risk that autorun raises. It isn't new anymore, but DarkReading's Social engineering, the USB way is still the best story the make the point. Check it out.

I really can't think of any business reason for keeping this feature enabled. Please shut if off, domainwide, as soon as you can.

In Windows Vista/Server 2008, go here:

Computer Configuration | Administrative Templates | Windows Components | AutoPlay Policies

Enable the "Default behavior for AutoRun" policy and set the default to "Do not execute any autorun commands."

Enable the "Turn off Autoplay" policy and set it to "All drives."

In Windows XP/Server 2003, go here:

Computer Configuration | Administrative Templates | System

Enable the "Turn off Autoplay" policy and set it to "All drives."

While this might be old news for many of my readers, disabling autorun still doesn't seem to be a common security mitigation. At a recent conference I was surprised at the number of folks who haven't considered the risks of leaving it enabled. Surely by now most of you have heard about how certain music CDs can spread rootkits in your network. Yeah, holding down the [Shift] key when inserting a CD-ROM or USB drive will bypass the autorun.inf file -- but do you really want to rely on individual users remembering this? Nope. Group policy is your security friend: put it to good use here and disable autorun right now.

(BTW, Sony is up to their dirty old tricks again.)

Updated, 22 September 2007. Turns out there's a registry key that keeps track of all USB drives your computer has ever seen, and this key will override the Autorun settings if you insert a drive that your computer has seen before. So in addition to changing Autorun, you'll also need to delete this other key. Write a little script and call it from group policy. Here's the key to delete:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

More details here.

Antivirus software -- who needs it?

Steve Riley — Sun, 23 Sep 2007 07:14:44 GMT

In the newsgroups a few weeks ago, someone asked about which anti-virus software is best for experts. This is a really curious question. I've been involved in computer security -- as a practitioner, a consultant, and an instructor/speaker -- for several years. I feel fairly confident in calling myself an expert. I don't run anti-malware on any of my own computers. Why not? It's simple: I know what to click and what to skip, what to visit and what to avoid. I have control over what I choose to open, what I choose to load, and what I choose to run. And yeah, before the question arises, every four months or so I run a scan, and I've never gotten infected with anything.

Now don't think that I run totally naked (the other residents of my house probably would object, and I shudder to imagine how hot the laptop would feel then, haha). Because there's no way to control what someone else might throw at my Ethernet port, I do run the Windows firewall. I also run with UAC enabled because I want IE's protected mode, but I configure the policy to elevate without prompting.

Am I saying that anti-malware is useless? Absolutely not. In many instances, and for many people, it's still necessary. But we can't ignore the fact that malware is getting more sophisticated. Nor can we ignore the fact that, as I have this conversation with other security experts and similarly-minded folk, I often ask this question: "When's the last time your antivirus or antispyware detected anything?" Invariably, the answer is, "Never."

Why administrative passwords will never be like nuclear missile launchers

Steve Riley — Tue, 21 Nov 2006 13:16:22 GMT

During the past few months many people have lamented that Windows lacks a nuclear missile style control option for administrator passwords. Surely you've read about or seen photographs of missile silos where two operators, separated by a distance greater than the span of a single human's arms, must each simultaneously turn a key in a switch to launch a missile. Such a fail-safe is important when considering missile launches: presumably a nation can't thus be committed to global thermonuclear war on the deranged whims of a single raving lunatic.

At first glance, it seems reasonable to allow for similar control over domain and enterprise administrator accounts. A while back I wrote about the fundamental requirement of trust in administrators; missile control-style passwords (is there some official term for this?) might lessen the requirement for such trust, goes the thinking. Well, I'm not convinced that the logic that works for missile silos extends to administrator passwords. Let's examine the differences.

It works for missile silos because the fail-safe is tuned to the characteristics of its environment. It takes two keys, each of which must be rotated simultaneously, and they're separated by around ten feet or so: therefore, two humans absolutely are required. To accidentally or intentionally launch a missile when not under orders, both people must be either equally stupid or equally insane -- and in the second case, also equally trust that each is, in fact, a criminal, rather than one acting as a double agent attempting to entrap the other. Furthermore, both operators perform the function in full view of a whole lot of government staff and military officers. The environment and the fail-safe work together to keep the deadly missiles in the ground. Another important aspect is this: the silo and its control system are designed by and operated by the same entity, the government.

Now compare that to a domain controller. Let's say that it's possible to enable a feature that requires entering two passwords. Where would you do this? A logon screen with two password entry fields lacks both physical and human separation: one person could enter both passwords if he or she knew them. It's no better with smartcards -- again, one person could insert both cards into the readers. Replicating a silo-like environment using a pair of computers isn't the answer, because unlike the silos and their control systems, Microsoft designs Windows but you operate it. The fail-safe works for the silos because of the required physical separation. Microsoft can't dictate, and certainly can't enforce, that you have two domain controllers, separated by at least ten feet. Not everyone can afford all the necessary hardware; plus, think of the demands that would place on space and power in a data center. And besides, even with separated domain controllers, a malicious admin need only to enter the first password or insert the first smartcard in one computer then wheel over to the other one and enter the second password or smarcard there. I'm not sure there's a way to check for simultaneous credential entry.

Separation and delegation of administrative duties is, of course, a good and important concept, one that we'll continue to refine throughout the operating system. There's a lot of power granted to administrators right now, this power we will help you segregate among multiple roles (humans) in your organization. But because of the nature of computer systems, any human granted a particular bit of administrative power must be trusted with that power. Computer systems and the data they store, process, and protect aren't silos; applying silo-style security is the wrong approach to mitigating security risk.

Did you know that you ALREADY have an e-mail policy?

Steve Riley — Mon, 11 Sep 2006 03:34:00 GMT

An email access policy can be expressed in one of two ways:

E-mail is mission critical to our business. Therefore, we permit employees to read and compose e-mail from any location in the world where employees can access the Internet, using either company-issued devices or public Internet terminals. This allows our employees to be maximally productive.
E-mail is mission critical to our business. Therefore, we permit employees to read and compose e-mail only from company-owned computers built and maintained according to IT standards. This ensures the security and integrity of our e-mail systems and data.

Which policy is yours? You can't have both, of course.

Selecting a policy should never be a technical exercise, and the decision isn't up to the IT department or even the security group. It's a decision the business makes. The decision begins with the answer to the question, "What does mission critical mean to our business?"

For some, mission critical means maximum access -- that no matter where an employee is, or what the employee might be doing, if there's a device with an Internet connection, the employee should do some mail. Timeliness is of utmost importance; the organization will accept the risks associated with using public terminals (and deal with any exposure caused by potential threats that materialize).

For others, mission critical means absolute integrity -- that the organization simply can't tolerate the risks associated with access from unknown computers and will therefore permit access only to those on the corporate network (or maybe connecting via a VPN, but even that can be too much for some).

Which definition of mission critical is yours? It can't be both, of course.

Outlook Web Access = your email policy

If your organization uses Outlook Web Access, then it's already selected its policy: the first one. An organization who uses OWA values anytime, anywhere, any-device access as being necessarily critical to the success of its business that it's willing to accept the risks associated with such access. Let's consider some of the risks of using public terminals:

Malware infects an e-mail message
Keystroke logging software steals credentials
Evil person reads and writes e-mail after a user walks away without logging out
Evil person reads left-over attachments sitting in the browser's cache
Someone shoulder-surfs (an employee at a competing organization, for example)

But yet, for many organizations, the benefits of OWA outweigh the risks -- and there's nothing inherently wrong with that. In some cases, it's possible to mitigate the risks. Returning to our list, consider:

Malware scanners on the e-mail gateway
Two-factor authentication like RSA SecurID or VeriSign Unified Authentication (note: while 2FA helps guard against credential theft, it's powerless to stop malware)
- The folks at CryptoCard have some interesting products, including a software token that you can run on a Windows Mobile device or a Blackberry for generating the token that you then enter into the OWA login page -- however, I've got no experience with their stuff
Forms-based logon with a timeout (using a browser cookie)
Attachment conversion like Messageware AttachView -- converts to non-cached HTML
Not being stupid

Risk awareness and mitigation: the security group's job

Our job, as security experts, is never to say "no." Rather, our job is to enable the business to succeed as safely and securely as possible. We do that by staying close the business, understanding (perhaps even anticipating) its needs, and making it aware of any associated risks. It's up to the business to make the decision. Then the work returns to us, and now we select and deploy appropriate processes and technologies to mitigate the risks we can, while perhaps simply ignoring or transferring (by buying insurance) the remainder.

I know of few organizations who choose the second e-mail policy: prohibiting remote access to e-mail. Indeed, I would wonder if that kind of organization really knows what e-mail is for. Work in the modern age is rarely limited to daylight hours in traditional offices. If your organization is among the majority that expects its employees to work for free (ha ha), then it's your job to make sure the business understands the risks and deploy appropriate processes and technology to mitigate those risks.

And this is only the beginning. Done right, an OWA architecture can be extended into a general access model that's simpler to design, build, and maintain; its simplicity results in cost savings and greater security. I'll have more to say about the "web-enabled data center" in a future blog post. My goal is to shove all DMZ-laden complex network beasts into the dustbin of history.

Configure your router to block DOS attempts

Steve Riley — Mon, 10 Jul 2006 23:27:00 GMT

Some time ago I had a discussion with a friend. He disagreed with my recommendations on how to configure a border router and the firewall behind it. I claimed that in the border router between you and your ISP, configure the six rules to block most denial of service traffic; in the firewall, configure additional packet filtering and content inspection. He claimed that it's better to repeat the router rules in the firewall, and if possible repeat the firewall rules in the router.

This struck me as disingenuous: "Why do the same work twice?" I asked. "It's defense in depth," came the expected reply. "If a bad guy gets through the router, maybe the firewall will stop him."

No, it isn't defense in depth. Defense in depth is about doing the correct things at all layers, and only things that are appropriate for each layer. When defense in depth degenerates into duplication of effort, the resulting security posture becomes more brittle and, arguably, less secure.

There are three kinds of vulnerabilities:

Code: an error in the software that you fix with a patch
Configuration: an error a human made while setting something up
Circumvention: an error in a security policy that encourages people to look for ways to get around the policy

By far, the most commonly occuring type (according to some research from CERT) is the second: configuration vulnerabilities. Given that it's far more likely for me to make a mistake in my rules than for the code in the router or firewall to be buggy, it's far more likely for a bad guy to break in through my error-ridden rules than for him to break in through a code vulnerability in either device.

Complexity is the enemy of security. Simplicity always wins. Therefore, to keep a network simple (and more secure), ensure that your defense in depth measures are tuned and specific for each layer, not merely duplicates of something you've taken care of at another layer.

Blocking DOS attacks

Now, back to the title of this post. In a border router, you should have six rules that will block almost all denial of service attacks. Remember the attack against the Internet in February 2000? Mafiaboy, the 17-year-old Canadian script kiddie, brought down 11 sites using 75 computers in 52 countries to send 10,700 messages in 10 seconds, causing an estimated $1.7 billion in damages. (Canadian police discovered him from his boasting in chat rooms. In 2001 he pled guilty to 56 charges and was sentenced to two years in a juvenile detention center).

Why did Yahoo, Buy.com, eBay, CNN, Amazon.com, ZDNet, ETrade, Dell, and Excite all succumb to the attack? Because they lacked one or more of these six important rules. MSN and Microsoft were targeted, but because our routers have these rules, we escaped the attack. The rules:

Block all inbound traffic where the source address is from your internal networks. Why in the world would there be traffic on the outside that originates from the inside? This is a sign that someone is spoofing you.
Block all outbound traffic where the source address isn't from your internal networks. This is the inverse of #1: there's never any reason for your network to emit traffic that's sourced from some other network. Somone on the inside is spoofing someone else (we have a term for such people: employee).
Block all inbound and outbound traffic where the source or destination addresses are from the private address ranges. Defined in RFC1918, these addresses are for use in internal networks; ISPs agree not to route such traffic. Of course, ISPs make configuration mistakes, too; I've seen traffic with these addresses on the Internet. So don't trust that your ISP is perfect, block the stuff yourself. And remember to include the Windows automatic private IP addressing block. The ranges, then, are: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16.
Block all source-routed packets. Way back in 1970, when "routers" were Unix computers running a routing deamon, they weren't all that reliable. So IP includes a provision for the headers of a packet to indicate the route the packet should take from its source to its destination. Source-routing was necessary then, but it's completely unnecessary today: routers are some of the most reliable gear around. Source-routed traffic is the sign of an attack: drop it all.
Block all broadcast packets, including directed broadcasts. Broadcasts are useful inside a network, but have pretty much zero utility between networks, so don't let the stuff in (or out). And good old smurf attacks, still seen as a form of revenge in IRC, rely on directed broadcasts. [Thanks to Michael Dragone for suggesting this additional rule.]
Block all packet fragments. Fragrouter is an old but wonderful tool, imminently useful for evading network intrusion detection. With it, an attacker can create packet fragments -- TCP or UDP packets missing the TCP or UDP header -- and, for example, map out your firewall policy and prod for holes and mistakes in your configuration. With one notable exception, fragments are generally not created, so there's no reason to permit them into your network. What's the exception? IPsec -- or, more precisely, IKE authentication in IPsec. During the authentication sequence, IKE performs six round trips between the peers. As the peers negotiate a protection suite and exchange keys, IKE generates fragments: very rarely will the key fit in a single packet. So if you're allowing IPsec between the Internet and something behind your border router, you'll need to skip this final rule.

There you go. Program these six rules in your border router (and consider dropping whatever else you've got there now) and you, too, can tell the likes of Mafiaboy to go pound sand. Oh, and guess what? By being more secure yourself, you directly affect -- negatively -- the security posture of your neighbors and competitors! Did you ever think that a router configuration could become strategic competitive advantage? :)

What do YOU need out of two-factor authentication?

Steve Riley — Fri, 21 Apr 2006 01:37:00 GMT

Two-factor authentication continues to grow in popularity and emerge as a security requirement for many people I meet with. At Microsoft, we use smartcards internally for VPN access right now; soon we'll be requiring smartcards for domain logon, too.

We are also looking at ways to require two-factor authentication for web-based services, like Outlook Web Access, published SharePoint servers, and other bits in our extranet. I love smartcards, and it's Microsoft's preferred product direction and corporate IT approach. But here we encounter a problem with them: most public workstations (kiosks, Internet cafes) don't have smartcard readers. So how do we require two-factor authentication when the infrastructure can't support it?

Ideally, my answer would be: too bad. Public workstations are too great a risk. No self-respecting organization would ever allow access to corporate resources from unknown machines, right? What possible business justification would ever permit exposure to such risk?

A lot, it turns out. Any organization (Microsoft included) that permits access to corporate resources, like OWA, is making a risk statement, whether they know it or not. That statement is this: "Our business activities require access to certain resources from any device, anywhere, at any time. We accept the risks associated with this because the value to the business is determined to be higher."

But just like us, many organizations are starting to become wary of these risks. Two-factor authentication can help to mitigate some, but not all, of them. The choice, then, is which kind of two-factor authentication to use? If smartcards won't work because readers aren't yet ubiquitous (they will someday -- remember, once upon a time a mouse was a rarity), what's left to choose? (I wish we'd include smartcard readers in every box of Windows we ship, just like we included mice in Office.)

Some form of token card with a one-time password is generally the option, with RSA SecurID being the most popular. Lately I've been reading about VeriSign's Unified Authentication product -- a number of you have mentioned your success with it, and you like that it integrates natively into Active Directly without requiring a separate authentication infrastructure (unlike SecurID, which requires an ACE/Server). I would like to play with this myself someday (hint hint).

I want to hear from you, though. What do you need from a two-factor authentication mechanism? What are your requirements? Have you used the products currently on the market? What do you like or not like? What do you want to see done differently? Would you like for Microsoft to develop something, or do you prefer to rely on partners?

Tell me what you think. Our IT department is engaged in a lot of research here; I'd like to know what you've learned in your research and through your experience, too. Post a comment here or email me if you'd prefer to remain private. Either way, I'd really like to get a good body of customer thinking on this. Thanks!

Domain controller security: it starts at layer zero

Steve Riley — Sat, 11 Mar 2006 00:15:00 GMT

Recently I seem to have had the same conversation over and over again, in places as far apart as Jakarta, Winnipeg, and Berlin. The question is usually worded like this:

"What happens if someone steals one of my domain controllers?"

There is, essentially, only one correct answer, which is this:

"You flatten and rebuild the entire forest."

Not very comforting, I know. Consider this example.

A customer once liked to display all their shiny computer gear behind a large plate-glass window that faced the street (complete with labels indicating the telephone numbers of all the modems, but that's a different problem). One day, some dishonorable thugs decided to help themselves to a computer, so they smashed their pickup truck through the window, snarfed the first computer they saw, threw it into the back of the truck, and sped away. It just so happened that this computer was . . . a domain controller! They called the police and described the truck and the theft; the police found the thieves, recovered the computer, and returned it to the customer -- who proceeded to reconnect it to the network. Alas, a very unwise decision.

Think about it for a moment: a bad guy had physical access to that which is the source of authority for every security principal in the forest. Who knows what he's done? Some possibilities:

Extract password hashes from the AD database (no need to crack the passwords themselves now)
Install malicious self-replicating code
Add rogue user, service, and administrator accounts
Create or modify logon scripts

Honestly, this is a machine you can no longer trust. And if the bad guy still possesses the computer and manages to reconnect that Typhoid Mary of a DC back to your network, and forces a replication to the other DCs in the forest, well...it frightens me to think of the ramifications.

Back in the Windows 2000 days, Microsoft published some best practices for securing domain controllers. Part II (which I've linked below) contains a section called "Recovering from the physical breach of a domain controller." Ten thickly worded pages guide you numerous manual and time-consuming (read: potentially error-prone) steps for working the bad guy out of your forest. I suppose all that might succeed, but really you can't trust that forest anymore. Rebuilding it from the ground up is your only practical choice. Yes, FDISK is your friend.

Managing risk

Regular readers of my articles and attendees at my conferences know the point I'm making here. In the case of domain controller physical security, the question usually arises when customers begin placing domain controllers in locations outside the central headquarters. For we in the United States, where connectivity is amazingly cheap and highly reliable, no one thinks of placing domain controllers in far-flung offices with only three people, two cats, and a creaky vending machine disgorging year-old pretzels (when it's in the mood).

But in other areas of the world -- areas where bureaucracy-laden telcos, often remnants of tin-pot dictatorships, dispense bandwidth as if it were glittering emerald encased in pure platinum (with stratospheric monthly charges to match) -- organizations must make a security vs. usability tradeoff. Security prefers that all DCs remain safe in a central data center and all authentication traffic traverse the WAN; usability demands that DCs be placed where the people log on because WAN links die so frequently. In this scenario, I hope you agree with me that usability wins: if the people can't log on, they probably can't do their jobs; secure environments are useless if idle workers can't access them.

Therefore, you have to accept the risk, and situate domain controllers as close to the people and resources as possible. I have two suggestions for mitigating risk.

Cage that beast. Numerous manufacturers offer steel cages in which you can encase your remote domain controllers. Limit your selection to those that include some form of physical anchoring, such as a large heavy chain attaching the cage to a bolt or eye screwed deep into a concrete floor. Be sure the cage includes a decent lock -- an electronic lock is best, one that can audit all access. Remember, you're protecting not only the hard drive but the whole computer.
Consider multiple forests and selective authentication. Surely you've learned that Microsoft long ago stopped recommending single forest/single domain AD designs; yes, we were wrong about that. Because the forest is the true security boundary, implementing multiple forests helps contain the spread of any compromise. But to make multiple forests useful, you need to implement trusts. Typically, those are unidirectional: central corporate resource forests trust distributed user forests. There is the potential, at least, that the central forests might be trusting a compromised forest -- at least for a time -- and could themselves become compromised.

A feature known as selective authentication lessens the risk. It's an authentication permission set on the security descriptor of the resource computer object located in AD, not on the security descriptor physically located on the resource computer itself. Controlling authentication in this way provides an extra layer of protection to shared resources by preventing them from being randomly accessed by any authenticated user in the trusted distributed user forests. Now, if one of these user forests is attacked and requires a rebuild, you don't have to rebuild the entire trusting forest also -- only the machines in that forest enabled with selective authentication of principals in the attacked trusted forest. See the second article below for more information on selective authentication; scroll down about one-third.

So protect those domain controllers! No, they don't store your company secrets; yes, they're pretty much just plumbing in your network, but I'm sure many of you have experienced the painful inconvenience and overwhelming urgency associated with malfunctioning plumbing... Plus, consider Active Directory designs that contain threats and mitigate risk. Perhaps my 60-second AD design will work for you:

Forests and domains represent geography (geography is stable and doesn't move -- much)
Organizational units mirror your administrative model (types of machines and people)
Security groups follow your organizational chart
Selective authentication, not mere trusts, controls and limits access

It's simple, it's effective, it removes the politics from the design, and you don't need to pay an army of too-smart-for-school suits -- I mean consultants -- to pretend to labor over a customized design "just for you" that's really the same thing they did for the previous 1,000 customers but still costs you dearly.

Best practice guide for securing Active Directory installations and day-to-day operations: part II
http://www.microsoft.com/downloads/details.aspx?FamilyID=c0dbeb7e-d476-4498-9f6c-24974fb81f1e&DisplayLang=en

Security considerations for trusts
http://technet2.microsoft.com/WindowsServer/en/Library/1f33e9a1-c3c5-431c-a5cc-c3c2bd579ff11033.mspx

It's me, and here's my proof: why identity and authentication must remain distinct

Steve Riley — Thu, 16 Feb 2006 20:41:00 GMT

My February Security Management column is posted:

http://www.microsoft.com/technet/community/columns/secmgmt/sm0206.mspx

No matter what kinds of technological or procedural advancements occur, certain principles of computer science will remain -- especially those concerning information security. I’ve noticed lately that, among all the competing claims of security vendors that their latest shiny box will solve all your security woes, a basic understanding of computer science fundamentals is missing. Because good computer science never loses importance, and because knowing the science can help you choose products and develop processes, from time to time I will cover such topics in this column. This month I’d like to explore the concepts of identity, authentication, and authorization, to help you understand their important distinctions, and to help guard you against the increasingly common tendency to combine the first two.

But I can't test! My boss won't let me

Steve Riley — Thu, 10 Nov 2005 00:19:00 GMT

Yesterday I mentioned that there's no substitute for doing your own testing of updates. I mentioned virtualization is your friend -- building a model of your environment using Virtual PC and Virtual Server will save you a lot of money and it's something you can quickly tear down and rebuild whenever you want. But what if you simply can't test at all, because you simply lack the resources -- time, money, whatever? (You also lack a good manager in this case, but that's a blog entry for another time...)

Check out what Susan Bradley recommends. Stop tweaking, engage with the community. Fewer tweaks increase the likelihood of updates working just fine; the community can be somewhat of an update testing mechanism for you. Technical people love to help, take advantage of the smart ones.