Steve Riley on Security : security policies

Attacks against integrity

Steve Riley — Wed, 21 Jan 2009 07:28:58 GMT

I’ve been mentioning this frequently during my talks in the last 12 months: that accidental or malicious data modification is yet something else we need to defend against. Richard Bejtlich wrote last year about attack progressions, and this year summarized an accidental integrity error that created minor havoc at Veteran’s Affairs health centers. Richard’s progression nicely matches our beloved friend, the infosec triad:

First they came for bandwidth... These are attacks on availability, executed via denial of service attacks starting in the mid 1990's and monetized later via extortion.
Next they came for secrets... These are attacks on confidentiality, executed via disclosure of sensitive data starting in the late 1990's and monetized as personally identifiable information and accounts for sale in the underground.
Now they are coming to make a difference... These are attacks on integrity, executed by degrading information starting at the beginning of this decade. These attacks will manifest as changes to trusted data such that those alterations benefit the party making the change. This sort of attack undermines the trustworthiness of data.

Alas, his concluding sentence is all too true:

If we think it's tough to maintain availability and confidentiality, wait until we security people are tasked with validating the integrity of data. It will happen after a celebrity dies or a group of "normal people" do, unfortunately en masse.

Get ready to start adding integrity protection to your data and incorporating integrity protection in your applications. Also: start making noise yourself, and let your vendors know this will eventually become a business requirement for you. Please, let’s not give the folks at the Privacy Rights Clearinghouse another category to track!

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.

Plan now to eliminate "power users" from your domains

Steve Riley — Mon, 11 Feb 2008 21:03:17 GMT

I've seen some conversations lately about the Power Users group -- how powerful is it, really, and why did we remove the group from Windows Vista?

That group had rights install software and drivers. And if you can install software and drivers, then you can elevate yourself to Administrator or SYSTEM. Vista includes a signed installer that allows standard users to install packages signed by a trusted root. (The "Trusted Installer" is a service that has a SID, so you'll see it in the permissions list on various objects throughout the operating system.) The installer validates the signature chain, then elevates itself to perform the actual installation. Now, standard users can install and update approved software without having to grant membership in the too-powerful Power Users group.

We deprecated the Power Users group and removed it wherever we detected it on ACLs. We recommend that you do the same.

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!

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.

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."

Password policies. Once again.

Steve Riley — Wed, 05 Sep 2007 01:14:00 GMT

Recently in the newsgroups (news:microsoft.public.security, to be specific) the question of password polices and the out-of-box defaults came up. The poster lamented a number of things: that Microsoft doesn't enable account lockout by default, that we don't have a built-in mechanism for automatically disabling unused accounts, that the 42-day default expiration is troublesome. Here's my response; figured that it would make for a useful blog post, too.

Account lockouts

Account lockout is a poor substitute for good passwords -- and is one of the most expensive security features you can use. Let's think about this by considering the threat. What threat does account lockout (attempt to) mitigate? Password guessing. How can you make password guessing attacks become useless for an attacker? Two ways: implement lockouts or use good (meaning long) passwords.

Consider the first choice, account lockouts. The typical cost to an organization to reset locked accounts is US$75 per help desk call. In a medium or large organization, this can become a very high monthly maintenance cost. In nearly all instances, the call results from users locking themselves out (too many vodka tonics on the plane, maybe?), not users encountering locked out accounts because some bad guy was trying to guess passwords. Account lockouts have one more -- very bad -- problem: they create opportunities for bad guys to conduct denial-of-service attacks against accounts or entire domains! Even if you use a timed unlock of, say, 15 minutes, then the attacker can write his script to churn through thousands of bogus logon attempts every 15 minutes 2 seconds. So, contrary to the claim, enabling this setting actually can have significant impact on usability.

Account lockout is there for people who absolutely need it. But I can't think of any instance where this is true. Instead, have a policy that requires simple passwords at least 15 characters long. Forget about complexity rules that force people to write down passwords. A simple 15-character passphrase (think short sentence) is easy to remember, quick to type, and far stronger than any short complex password. A passphrase like this will withstand any kind of automated password attack, including those based on rainbow tables. And you can even use a method that helps you remember unique phrases for each site, if you wish:

web mail: "my dog and i got the mail"
shopping: "my dog and i bought some stuff"
office: "my dog and i went to work"

This is why we disable account lockout by default. There are much better -- and much less expensive -- ways to mitigate the threat.

Disabling unused accounts

You're right, there's no built-in method to automatically disable unused accounts. A variety of third-party products can provide you with this functionality. I suspect some of them might be free, perhaps simple scripts even. I tried searching on "automatically disable unused accounts" and saw a few hits that looked promising. This particular function, however, rightly belongs in the HR process. A number of customers I've spoken with have automated the account creation/disablement/deletion process, incorporating it into HR systems. When a new user is hired, the account is created; when the user departs, the account is disabled; some time later, it's deleted. The HR systems take care of this, not domain or enterprise administrators. I wrote more about this subject in "When you say goodbye to an employee."

Password expiration

Password expiration is an important setting for everyone. It mitigates two threats: employees sharing passwords and bad guys discovering passwords. Because we can eliminate the second threat using long simple passphrases as I described above, then we have only one remaining threat: password sharing. Your estimation of how prevalent this threat is in your environment will guide you toward choosing an expiration time that works for you. 42 days is a reasonable default; our own corpnet uses 70 days. My experience with most customers shows that password sharing isn't a problem. So for those who do enforce long simple passphrases, I suggest that a reasonable default for expiration is 120 days.

Windows begins notifying you 14 days before your password expires. You can change this time period through group policy. I was in a similar situation recently. Last month my domain password expired while I was in Australia for TechEd there. I could continue to log on to my laptop with cached credentials, but couldn't use Outlook Web Access or RPC+HTTP of course. So I connected to a Terminal Server computer we have on the Internet, logged on there, and changed my password.

When you say goodbye to an employee

Steve Riley — Thu, 31 May 2007 21:29:45 GMT

...what do you do with his or her account? Recently this question came up -- someone was asking for guidance on how to handle this very situation. And, as often happens, the question was more about process and policy than anything to do with the technical issues of account management.

Those of you who've followed my writing and speaking will agree when I admit that I've become somewhat of a policy wonk over the past few years. Awhile back I spoke at an executive event in Taipei. I asked this question: "Who here can claim that their network is completely secure?"

Much to my surprise, a gentleman in the front row said "I can."

I honestly wasn't expecting that answer, so I decided to probe a bit. "Really? Wow. That's cool. How can you know that?" I asked.

His response: "Because I've installed every security product I can find."

...uh...hmm...it's unusual for me to be at a loss for words! But sensing a teaching moment, I talked for a while with the audience about risk assessment, about business drivers as the source of policy and process, and about technology as the implementation of some (but not all) process. It was a good conversation, one I've had many times since then.

You can twiddle all you want with various pieces of technology, but unless you have well-tuned processes that derive from policies reflecting the needs of the business, then your technological efforts are wasted. Very likely you'll end up focusing on threats that don't exist while ignoring those that can seriously bite you.

There are some elements, though, where you really don't need to worry so much about extensive process or looking to map from business drivers to policy to process. One of these is what to do with the accounts of ex-employees. While people become ex-employees for a variety of reasons, there's really only one threat that exists: all access by ex-employees is by definition unauthorized access. So as I see it, there's actually a very simple process for handling their accounts, and here it is:

Immediately disable accounts when users quit, get put on probation, or are fired
Delete these accounts when you no longer need them for recovering data

There's certainly no business requirement for keeping an ex-employee's account active. That's why you should disable it right away. If you instead immediately delete an account, you've made it nearly impossible to retrieve information that the employee has encrypted. The default recovery agent is a backup for EFS, but you need to have configured it correctly when you implemented EFS. However, for S/MIME there is no backup. Plus, in case you need to conduct any kind of investigation, you might need to log in to an ex-employee's account. So to be safe, disable it -- but keep it for a while.

Only after you're certain that you won't need it anymore can you then delete it. You don't want it to hang around forever, because for so long as it exists, it's something you have to manage. So when you're finished with it, after you've completed any investigations and have recovered whatever data you need, get rid of the thing. Now you can forget about it.

I see two remaining considerations. The first: it's up to you to determine the time interval between disabling and deleting. Here's probably the only point worth some thought in this process, and it's mostly about responsiveness. How much time can IT give the business units for completing an investigation and recovering data? Perhaps you'll have two time limits:

one for when no investigation is required (say 30 days for general collection and clean-up)
one for when there is an investigation (it's out of IT's hands, let the legal department decide -- but the duration should never be infinite!)

The other policy/process consideration is determining what data of the ex-employee to keep. I suppose "keep it all" would be one choice...but do you really need all the MP3s and porn that guy has collected? Unless you're investigating resource abuse, probably not! Here's an opportunity for you to work with the business units to decide -- most likely on a case-by-base basis -- which data to keep and which to discard.

Handling the accounts of ex-employees is pretty simple, really. So don't get too mired in arcane process work here. There's far more important work you need to be doing.

Enabling Secure Anywhere Access in a Connected World

Steve Riley — Tue, 06 Feb 2007 23:47:00 GMT

A few times each year, Bill Gates or Steve Ballmer publish an executive memo. The first memo was Bill's essay on trustworthy computing, in July 2002. Today Bill has a new memo, one that is very important for all of us who strive to achieve a balance between being secure and, well, getting work done.

Some of my favorite points from the memo:

[It] is no longer a question of the power of our devices and the speed of our connections. The real issue today is security. Ultimately, anywhere access depends on whether we can create and share information without fear that it will be compromised, stolen, or exploited.
No company is immune to the danger. Malware targets products from virtually every software vendor. Every business is vulnerable to the risks that come with unauthorized access to corporate information.
...striking the right balance is extremely difficult. Easy access speeds communications but increases the danger that confidential information will be exposed. Stringent security measures reduce risk, but can make it too difficult for employees to access information or communicate with customers and partners and too complex for IT professionals to deploy and manage solutions.
...new technologies for managing the way people and information move between corporate networks and the Internet are essential. In the face of a rapidly evolving threat landscape, the firewall...is no longer adequate.

Several times in the memo Bill mentions the importance of policy. Most of you have probably heard me speak of similar ideas. Policy-based security allows us to finally divorce information protection from the mechanism used to transmit that information. This is essential because the ubiquitousness of mobile computing demands it. Regardless of where information is stored, how it is transmitted, policies that apply to the information will move everywhere with it. We will no longer be constrained by the topologies of any particular network, because the network will lose its role in managing access to information and revert to the single thing it does best: move bits around as fast as possible.

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? :)

Security myths and passwords

Steve Riley — Sun, 30 Apr 2006 19:07:00 GMT

I like this a lot.

http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/

In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous.

Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom.

From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place. Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses. “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.

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!