Steve Riley on Security : security science

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.

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.

It's time to stop playing war games in the name of "security"

Steve Riley — Tue, 14 Mar 2006 08:07:00 GMT

Really interesting article.

Military mindset no longer applicable in our line of work
http://searchsecurity.techtarget.com/columnItem/0,294698,sid14_gci1171862,00.html

My favorite bit: "Obviously, secrecy is important to business, as is the ability to trust messages to the military, but these two camps have opposite priorities. For example, if we had developed a business approach that ensured transactions were genuine instead of a military approach that protected the secrecy of credit card numbers, ID theft wouldn't be an issue today."

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.

Return on security investment

Steve Riley — Tue, 03 Jan 2006 21:40:00 GMT

Soon I will begin a research project into quantifying and expressing return on security investment. From conversations I've had with many conference attendees, there's a need for developing a basic understanding of how to measure ROSI so that budget money for security magically becomes unlocked. I plan to assemble a presentation on this for 2006's events.

If any of you have personal thoughts on ROSI, or some tips that work for you, please comment here or email me (steve.riley@microsoft.com). I'd love to include your ideas. Thanks!

Lousy security

Steve Riley — Wed, 14 Sep 2005 01:33:00 GMT

Lousy security is all around us, and I'm not even thinking about airport security here (which, I admit, i love griping about). Here I have in mind lousy computer security. And lest you think I'm proceeding to engage in naval-gazing introspection, no -- I'm not going to write about our own products.

Jesper already wrote up his impressions of a popular wireless router. Now I'd like to tell you about some software I encountered recently.

Rights management systems (no, not evil DRM that stops you from using, on your own devices, music you've purchased) are becoming more critical in business information systems these days. It's becoming more and more difficult to use a network function -- in this case, file system ACLs -- to enforce access control to objects that can live in many places outside the network. This is the beauty of rights management systems: they offer you a way to enforce access control no matter where an object resides.

Sure, we have some pretty cool rights management stuff. But I'd like to tell you about another one. Recently at an event Jesper told me about a vendor who approached him. This itself isn't so unusual. But this gentleman was bubbling over with excitement about his new rights-management system that was entirely client based -- unlike Windows RMS, it required no server infrastructure. "Hm," thought I, and I agreed to let him show me the product.

Operationally, it was fairly straightforward -- while their software is running, any documents you create can be protected through the system. On the hard drive it's just an AES-encrypted blob. Good so far. I started chatting with him about how authorization is enforced, and while listening I tried an experiment. I had Jesper open a protected Word document inside Notepad -- always a good thing to do if you want to get an idea of how a file might be modified. At the top of the file was some XML, followed by random binary goop. Sure looked encrypted all right. Then I said, "Hey, save that thing right back to the hard drive and re-open it in Word," wondering whether a simple read-save in Notepad would do anything to his system.

We loaded Word, opened the document, and -- yes! -- a blue screen! Wham! Cue rapid expressions of surprise and fear across the sales robot's face.

What happened here? Originally the document was in Unicode. Notepad saved the file in ANSI. Obviously, then, their protection system is incapable of handling non-Unicode files, and the developers made the disastrous assumption that all input is valid. "Who would ever do that?" must have been their answer to the question "What if someone tries to open a non-Unicode file?" Probably, though, they never even thought to ask the question in the first place. The system should have checked the collating sequence and either rejectd non-Unicode files or adjusted for ANSI.

Now why do I relate this tale? It's simple -- software is difficult. Good software is more difficult. Good secure software is monumentally more difficult. Thinking about how a bad guy might abuse your application and developing reslient software that doesn't just blow up in the onslaught of attacks is something that the entire industry is only now beginning to figure out. Jesper's even talking about this now and demonstrating the good and bad in a new event session called "Is that app really safe?"

People bash Microsoft stuff for being insecure, but at least we have dedicated people whose job is to try to break our stuff. We've got the resources to do that. I'll tell ya, sometimes I'm not sure about some third parties, especially those selling "security software." Conduct your own dilligence, test the crap out of anything before you buy, and reward good vendors with your money.

August article: 802.1X on wired networks considered harmful

Steve Riley — Thu, 11 Aug 2005 20:55:00 GMT

Several months ago I learned from Svyatoslav Pidgorny, Microsoft MVP for security, about a problem in 802.1X that makes it essentially useless for protecting wired networks from rogue machines. Initially I was a bit skeptical, but the attack he described is in fact true -- I've seen it myself now. So I've been explaining the attack at conferences lately and have also included information about it in the book. However, I don't believe the danger presented by wired 802.1X is getting enough reach, so I've written about it in the August security management column.

As you read the article, remember that the vulnerability enabling the attack is a fundamental weakness in the protocol -- it authenticates only upon connection establishment and assumes all traffic after authentication is legitimate. The vulnerabiliy exists in wired networks because there's no follow-on packet authentication. You really should be using domain isloation with IPsec to thwart rogue machines, and at the article's end are links to information about that. Also, understand this particular vulnerability isn't present in 802.1X-protected wireless networks, because the authenticators and supplicants have established authentication and encryption keys that protect individual 802.11 frames.

Airport security silliness

Steve Riley — Fri, 22 Jul 2005 06:23:00 GMT

So today (Thursday 21 July 2005) I flew from Seattle to Dallas for a customer meeting. Since it's a short one-day affair, I packed my small carry-on size suitcase. In it was a pair of shoes, one pants, one shorts, two shirts, a toiletry bag, and my collection of wall warts (AC adpaters). Seems normal, so far.

As the suitcase passes through the x-ray machine, the TSA droid's brows begin to furrow. "Oh crap," thought I. They run the bag a second time. More furrowing.

"Is this your bag?" they ask. There seemed to be a bit of trepidation combined with glee in their attitude -- or maybe I was just imagining it.

"Yeah, can you tell me what's wrong?"

"There's something that we can't figure out what it is. We'll need to do a secondary screening."

So then they carry it to one of those infernal explosive detection machines. You know, where another doughnut-gorged TSA droid sticks a little chamois pad on the end of a wand and lovingly caresses your bag's zippers, then inserts the chamois pad into the detection machine. There was nothing, of course. As far as I can tell from my research, none of these machines in any airport in the United States has ever actually found an explosive. What an absolute waste of time, money, and resources.

Then -- get this -- Mr. Doughnut hands me my bag! So let me get this straight. The supposedly highly-trained x-ray operator can't figure out something inside my bag, and so they inspect the exterior zipper? What are these people smoking, and why don't they share? Sheesh! Security theater, indeed.

New column - debunking security myths

Steve Riley — Tue, 12 Apr 2005 22:58:00 GMT

There is a lot at stake in security configuration guidance. First, it is easy to understand why people are clamoring for it. Everyone can see the benefit in turning on some setting and blocking an attack. In some environments, doing so is not even an option. A system must be configured in accordance with some security configuration or hardening guide to be compliant with security policy. In other environments security configuration guidance is strongly encouraged. Before you start making security tweaks, however, we feel that it is very important that you understand some of the fundamental problems with them. These are what we call the myths.

Part 1: http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx

Part 2: http://www.microsoft.com/technet/community/columns/secmgmt/sm0405.mspx