If you keep abreast of what folks in the security industry are talking about with any regularity then you’ve probably read something lately about how the current economic crisis might affect corporate information security. For instance, layoffs could result in the loss of key security personnel and/or trigger retaliation from bitter employees. Others are worried that slashed budgets won’t allow security programs to buy what they need to buy, or do what they need to do. The list goes on.

[Midstream update: As I type this, I see The National Bureau of Economic Research has declared we’re officially in recession. Shocker. In other news, government sources also confirmed that temperatures in June were higher than in January.]

Despite what the title may lead you to believe, this post is not an attempt to refute these or other related hypotheses. In fact, I think there are some grounds for legitimate concern and I’ll be very interested to read any future studies that test whether or not the economic crisis had a significant impact on security (by the way, we do have our Investigative Response team looking out for signs of retaliation). What I haven’t seen yet are predictions that security will improve in 2009 due to the economic crisis. That may be because it probably won’t,  but it could.

To make my point, I need to ask you to engage in a willing suspension of disbelief for the next few moments. Ready? Great, here we go.

Imagine, if you will, that your security budget has been chopped in half. Rather than following the example of many other organizations by spending 50% less on $NewSecurityThings, you decide to be different. Instead, you purchase only a few very critical $NewSecurityThings and do four things with what remains of your measly security budget:

1)    Make sure your $OldSecurityThings are actually doing what you think they’ve been doing up to now.
2)    Remediate any deficiencies found in Step 1.
3)    Spend some time trying to identify and classify unknown or forgotten systems, data, connections, privileges, etc.
4)    Apply $OldSecurityThings from Step 1 to discovered assets.

It’s not a proposal likely to wow or frighten more money from the financiers but based on our experience it’s one that could dramatically improve security for most organizations in 2009. What do you think - have I lost my marbles?

Should Microsoft have patched SMB sooner? Why? Who has been adversely affected by the vulnerability? We’ve never had an Incident Response case that involved abuse of it. Given the fact that we now know there was a solution to the puzzle, chances are that solution was stumbled upon by accident in one of those “Eureka” moments. Once that idea was finally conceived, of course, it made sense for them to produce a patch, but do try to appreciate just what was at stake as they attempted to implement it and test it. Thousands, if not hundreds of thousands of 3rd party applications are based on SMB working just the way it does. Break it while patching the vulnerability and you’d have a lot of upset people.

First of all, you should know that the SMBRelay tool was intended to implement cracking concepts that had been published years before in a form that would automate the process of collecting and cracking password hashes. Previous tools took, for example, password hashes from the registry and cracked those. This required access to a server that had stored hashes (typically, a Domain Controller.)

SMBRelay was intended to avoid the need to actually compromise the DC, and instead collect the information off the wire. Sniffing password hashes had been known, and done, for many years prior to this. To crack an NTLM password hash one had to “guess” the challenge value that was sent by the server and used by the client to encrypt their password information. SMBRelay avoided this problem via man-in-the-middle proxying of the challenge/response traffic. In this way it would know the challenge value sent by the server and used by the client.

However, using Rainbow Tables is another effective method of cracking the client response obtained simply by sniffing the wire, thereby avoiding the need for any obvious system on a network.

Microsoft created NTMLv2 in an effort to strengthen the challenge/response encrypted presence on the wire to make sniffing less effective. Other features (SMB Signing, LMCompatability Level, etc…) were also introduced to mitigate some of the threats to NTLM.

At the end of the day, however, Microsoft could not avoid sending the response over the wire to the server. As such, it remained available to sniffing or stealing by any server the client attempted to authenticate against.

In other words, the vulnerability was present long before SMBRelay was ever published, and well understood by the security community (and hopefully Administrators of Microsoft systems.) It has certainly been demonstrated many times in penetration testing settings, but its actual use “in the wild” has never been documented (despite comments by Sir Dystic that suggest how easily this could be done via an email.)

SMBRelay offers one benefit that sniffing doesn’t; namely the ability to obtain the password hash from outside of the source network. However, to do this the source network must not only allow outbound traffic on port 139, but also inbound traffic on the same port, presumably from any address on the Internet. Many years ago abuse of the Windows Messenger Service (the one that provided a way to pop up a message on another system in your network) finally convinced many that they needed to block SMB from the Internet. Subsequent worms exploiting vulnerabilities in the server service convinced the others, including most home users. In other words, the benefits of SMBRelay versus local network sniffing have long since been thwarted.

It appeared that the only way this vulnerability was ever going to be “patched” was by Microsoft dropping NTLM altogether and opting for some other authentication protocol (such as Kerberos, which is where they’re going.)

Now Microsoft says that after many months of testing they finally believe they have patched the issues involved in SMBRelay. It is important to recognize that they have not fixed NTLM, or the ability to sniff hashes off the wire (unless you use SMB Signing.) They have, presumably, introduced functionality in SMB that can detect when a client’s own challenge response is used against itself, hence the term “SMB Credential Reflection Vulnerability.”

Finally, we come to the question of why now, or why so long after the tool was first published?
We believe that this issue could have been resolved sooner if there were actual threats in use. We believe that without actual exploitation, Microsoft simply worked on issues where there was a real threat, such as the out-of-cycle patch offered on October 23rd, 2008.

So kudos to Microsoft for finally addressing the issue, and a special congratulations to whomever came up with the idea of how to fix it. It took a lot longer than seven years to address this, given it was there for at least 8 years before Sir Dystic ever mentioned it.

At the time of his announcement, we advised our customers that this issue is really nothing new. Criminals have been able to obfuscate what you were clicking on for many years, whether it be via masking the real URL with a fake display value, or using an image map to cause a click anywhere on a page to invoke their desired result.

Since we ask our customers to always consider risk, we explained how there was no new risk here. To be exploited, you still have to visit a criminally-controlled site. Whether that’s a good site with bad advertisements, or one that’s been completely compromised, it still has to be compromised and you still must click your way there. More importantly, this issue requires that you actually click on something…unlike so many others where simply visiting the page could cause a drive-by download to occur without the user’s knowledge. Ergo, this issue is even less likely to be abused. Further, at the time of disclosure, we weren’t aware of any sites that were actually attempting to exploit the vulnerability.

In other words, the risk landscape hadn’t changed.

So now there’s a patch for it, and the obvious question is whether this needs to be applied overnight, over next weekend, or over some other period of time. After all, Microsoft states it’s critical, right?

Well, to start with, anything to do with Internet Explorer, in our book, should be addressed within 30 days of its release…be that a patch, Service Pack, or whatever. Clearly that includes a component such as XML Core Services, given how many sites use it today. So 30 days should be your initial goal.

As to whether this warrants sooner adoption by the business community, simply ask yourself this: Do you have users who are being compromised today? If not, then this new vulnerability isn’t going to change that. If so, then here’s another way for those individuals to shoot themselves (and you) in the foot, so consider them your initial targets. In any event, we haven’t seen any changes in the risk landscape that suggest you need to spend overtime dollars on this patch (or MS08-068 which also came out today.)

Let us not forget that this vulnerability was disclosed as part of a talk given at a show where people paid money to see things…not as a result of some rampant bot-herder attempting to build a million-zombie army.

Such a statement will make many jump to the conclusion that the state of crimeware is getting worse. But such a conclusion may not be accurate. For example, the increase in distinct computers cleansed in this latest period is just under 50%, whereas in the 2H07 report the increase was just over 79%. The increase in 1H07 was 95%. So the percentage increase this time around is smaller than it has been previously. The same can be said for the number of distinct infections cleansed. 1H08 was 47% higher than 2H07, but 2H07 was 219% higher than 1H07 and 1H07 was 80% higher than 2H06.

No matter how you look at the numbers there’s no discounting the fact that Microsoft cleansed more than 23 million unique computers of some form of crimeware in the first six months of this year, and that’s a lot of computers in anyone’s book. Consider too that these were on systems that likely had 3rd party anti-virus products on them as well, so the total number of infections is likely much higher.

But even this must be caveated as Microsoft points out the geo-specific reasons that contribute to the overall totals. Lesser industrialized nations or nations with smaller per capita Internet usage are among the highest infected nations. Clearly awareness, and experience, contribute to increasing the effectiveness of security.

Of more interest to us was Figure 81 on page 134 of the report titled, “Computers cleansed by threat category, in percentages, 1H06-1H08.” For in that table is an extremely important number, namely, the “Exploits” value of 1.0%.

All other categories listed in that table, such as Trojan Downloaders and Droppers, Worms, etc., are the result of user-initiated crimeware. Exploits are the only threat category which Microsoft attributes with a patchable threat. So whether it’s an iFrame running unwanted JavaScript, or some criminal automatically installing a criminal browser helper object via MS06-014 (MDAC/RDS), if it’s happening because of a software vulnerability it’s an exploit.

So consider the fact that all of your patch-o-mania (your massive roll-out of updates instantly after Microsoft releases new patches), inquiries to us about just how bad a given Microsoft Security Bulletin vulnerability could get, or overtime weekends trying to reach out to all of your roving uses to get MS08-067 installed is all to address a threat which represents a mere 1.0% of what Microsoft cleans off of machines each month.

Think about that for a second.

Now let me throw another zinger at you. You know all that talk there’s been about phishing? Well, according to Microsoft (who not only has its Exchange Hosted Services but a small web-based email site called Hotmail! Or Windows Live) phishing represents a mere 2.5% of criminal email (which we define to include spam, viruses and any other unwanted email). Yup, that’s right, while criminal email accounts for 90% of all email you receive, only 2.5% of it is a phishing attempt. See Figure 37 on page 67 for some useful insights into the kind of email problems you should be worrying about. For example, according to Microsoft blocking out anything to do with pharmaceuticals could reduce criminal email by more than 50%. Now clearly we have been under the impression that a lot of people have succumbed to phishing scams to get their bank details, and we’ve been led to believe these activities are being carried out by gangs of highly organized criminals - heck, even Microsoft’s own report on the Threat Landscape paints this picture -but at the end of the day the criminals are spending far more time hawking fake drugs via email.

Not to beat a dead horse, but in case you didn’t know it, Windows Vista appears to be more robust than other Microsoft operating systems. For example, just compare the number of machines cleansed per 1000 instances of the Malicious Software Removal Tool (MSRT) running; Vista SP1 with XP SP3 – 4.5 to 9.2. Want to see an even better number? Then look at Vista x64 SP1 where the number drops to 2.3. Think that XP SP2 is “good enough?” Think again, 11.2 to 9.2, SP2 versus SP3. We won’t even get into numbers involving SP0 or SP1, except to say that SP0 is 33.8.

As you can see, and as we have emphasized for years, deploying service packs is actually far more important than deploying individual security bulletins.

Finally, we’ve a move afoot here to be increasingly more global…after all, we are a global company. The media tends to focus on U.S. or Euro numbers and forget about other places in the world. Brazil, for example, has had a bank login stealing Trojan (called Bancos) cleansed off of more than 60% of the systems Microsoft sees in that country…that’s ridiculous!

If you happen to have systems in countries where the population is less than familiar with being connected to the Internet (regardless the skill level of your own users) then take Microsoft’s observations about such countries to heart. Consider what the cleaning staff might do with a system that doesn’t invoke a password-protected screen saver. Think about whom else might use a roving laptop while it is at home connected via a VPN. Realize the pressure your employees might come under from friends and family to get some cool, but free, game the kids heard of from friends. In these environments you have to provide a locked down desktop, one that prohibits, or makes it extremely difficult, for users to install software (especially browser components.) Internet Explorer 7 and Windows Vista are really your friend here as the combination truly affords you easy and excellent mechanisms for desktop lockdown.

All in all, we won’t say we’re encouraged by the report’s findings, but we certainly aren’t seeing the cup as half empty either. Browser exploits are far fewer than generally thought and phishing is much less common than other kinds of criminal email. That can’t be a bad thing! It is also worth noting that despite many pundit claims to the contrary, our #1 task has to be to educate the user to make more sensible and secure choices in their actions. If you believed there was a silver bullet coming down the pipeline that would solve your users’ issues, this report should put that idea to rest for another 10 years.

Microsoft rarely releases these out of cycle patches, but when they do lots of people get excited. It should come as no surprise that we aren’t.

If you want to get an idea of what could happen as a result of this vulnerability, think MS06-040/Graweg/Mocbot/SDBot/August-September 2006. MS06-040 was a similar vulnerability which allowed criminals to gain control of systems they could reach via Server Message Block (SMB). Of course if you can get to someone’s machine via SMB, there’s a lot of harm that could possibly be done.

Of course, we would like to believe that corporations are doing an adequate job of preventing SMB into their networks from untrusted sources. Obviously, this has the potential to storm around inside an organization if an infected host is brought in from some foolish exposure. In particular, think about partners you deal with who aren’t as well funded as you, or that remote support technician who wants to use his/her privileged access to that black box you currently have handling payment processing in order to gain access to your sales database.

Yes, exploitation potentially “wormy”, but we had two other vulnerabilities patched on the 14th that were also “wormy.” We’re not going to ignore the potential of an inside infection (e.g. within your LAN), but a lot would have to happen before that takes place (as in CNN reporting a worm spreading rapidly).

In short, only you know the state of your roving/remote users. Can you or should you consider blocking SMB from them? Do think about it? At least until they’ve been patched? Focus on those high risk users (e.g. executives) and any users with permitted less secure configurations. You should also move to protect critical infrastructure assets.

Although Microsoft say they have seen attacks, they qualify them as “limited, targeted.” That’s in line with current criminal activity.

“Attacks vary, therefore risk management doesn’t work.” To be fair, that’s not a direct quote from a recent Dark Reading article entitled “Why Risk Management Doesn’t Work”, but it is an accurate expression of its message. Like us (and Alex Hutton of RMI), you may be thinking that something about that message doesn’t seem quite right. Congratulations – you’re a logician.

Non sequitur is a Latin phrase meaning “it does not follow.” It applies to an argument where the conclusion does not logically follow from the premise. Need a good example? Check out the Dark Reading article which discusses our 2008 Data Breach Investigations Supplemental Report. Actually, the article itself isn’t bad; it does a fine job covering some of the findings from our report. My main objection is with the logical conclusion implied in the title which, oddly, doesn’t seem to square with what the article spends most of its time discussing.

The Supplemental Report highlights how the sources, causes, vectors, consequences, etc of breaches differ - often substantially - among industries. What do those differences mean for risk management strategies? I suppose that depends on who you ask. The Dark Reading article seems to imply that such variations invalidate the practice. We argue to the contrary – these findings establish the need for risk management. The logical reformulation of the message above is:

Premise: Attacks vary.
Conclusion: A security program that fails to account for variation doesn’t work.

Risk management is a process that (should) help organizations decide which controls should comprise their security program. Doing it correctly tailors the program to account for each organization’s risk profile and appetite. If it’s not working, it probably has more to do with how the process is conducted rather than the process itself. As advisors to our organizations in matters of security, let’s make sure our conclusions are grounded and our logic doesn’t take leaps.

We humans introduce risk regardless of our good intentions.  We security types tend to be a paranoid lot, thinking every unfortunate event is evidence someone is out to get us.  Yet we are regularly reminded of Hanlon’s Razor, quoted above.  Recently, we have two high-profile “oopsies” which demonstrate the premise of Hanlon’s Razor, namely that not all bad outcomes have an evil-doer involved.

Last week, a colleague at Verizon Business wanted to inform his customers and colleagues that we had published a supplement to our Data Breach Investigations Report. He crafted an e-mail message and used a list of addresses from a public (non-Verizon) website for the “To:” line in Outlook.  Oops.  He had intended to use the blind carbon copy (BCC) address line to ensure privacy of the recipients, but this did not happen. Certainly, in this case, his actions counted more than intentions.  Of course, he knows this is an easy-to-make error and thus one to guard against.  The earliest instance I’ve found of this bcc mishap dates back to 2001, but we can be pretty sure this mistake is older than that.

This issue really spun out of control internally when partially complete reports began circulating.  A quick Google for “Verizon Business” and “e-mail” led to a blog entry titled “Clickjacking attack info revealed;Verizon plays fast and loose with the wrong 1,200 e-mail addresses.”  Oops.  Without taking the time to read the actual blog article, some folks turned this into “we’ve been the victim of a clickjacking.” This belief then began to circulate among some of the security teams here.  At this point, the logic is along the lines of:
•    Something bad has happened.
•    Clickjacking is all over the news as the latest, greatest threat in Internet security.
•    Therefore, something bad was caused by clickjacking.

Still others applied Occam’s Razor, which plays out this way:
•    We’re sending out a mail storm.
•    Mail goes out through Exchange.
•    Occam’s Razor stipulates that the most simple explanation is probably the best one.
•    Therefore, we must be having problems with our Exchange server.  Oops.

The RISK Team here at Verizon Business routinely sees reports of the latest, greatest risk to Internet security, and reports of it being in the wild.  More often than not, the latest risk is not the greatest, nor is it in the wild in any meaningful way.  So reports of Verizon Business, indeed a security professional @ Verizon Business, being the first known victim of a clickjacking attack was met with a measure of skepticism.  Fortunately, we had a global RISK review conference call scheduled the same day.  Doubly fortunate in that a close co-worker of the e-mail’s sender attended the call, and we were able to quickly sort through to the facts.  Oops.

Don’t you just hate it when facts get in the way of a perfectly juicy rumor?

But why, you may ask, was the e-mail repeatedly re-sent, a reported 17 times?  There are over 32,000 of us here.  You might, therefore, imagine e-mail storage is one of the challenges faced and conquered by our IT department.  You might imagine we learn to save our e-mails locally in an archive or Outlook PST folder so as to avoid bumping into “your mailbox is full” warnings.  You also might imagine sometimes well-intentioned individuals create Outlook rules to help with this and one of those rules resulted in this particular e-mail generating a storm. Again, oops.

Humans introduce risk, and not all mail storms are the work of the Unimailer.

Cisco has also had a reminder of a well intentioned “oops” when someone’s music CD was used as the master for mass duplication of a support CD for some VPN hardware.  Neither industrial espionage nor a deliberate reputation attack was behind this error, just someone who listens to music at work.  Oops.

“It’s not paranoia when someone really is out to get you” is the aphorism based on a remark from former Secretary of State Henry Kissinger. But we need to bring our critical thinking skills to work every day.  Unfortunately, digital communications do not prevent a game of telephone, indeed they make it go at the speed of light.  Both Hanlon and Occam’s Razors are indispensable tools security professionals cannot risk being without.

Listen

Today, we released a supplement to our 2008 Data Breach Investigations Report (DBIR) that focuses on four major industry groups. As many of you know, the original document compiled four years of data from over 500 cases worked by our Investigative Response team and was intended to be a kind of “state of the union” look at recent security breach and data compromise trends.

The DBIR presented statistics in aggregate across all organizations in our caseload and did not delve into the state of affairs within each of the industries represented. Drawing from the same data set as the original, the Supplemental Report provides this analysis for the financial, technology services, retail, and food and beverage industries.

You probably can’t read it on the miniature cover shot above (you can if you download the full report here) but part of the subtitle reads “Industry Focus. More Analysis. Greater Insight.” It might sound like unadulterated marketing mumbo-jumbo but it’s actually a fitting description of what we feel the report accomplishes. Sure, it looks more closely at a few industries and provides more analysis, but the real value is greater clarity and insight into the original data. Why? Well, you can read the report for a complete answer to that question but one of the major reasons involves that age-old enemy of statistics, The Flaw of Averages. Any time you average a bunch of data points, the result is a middle-of-the-road expression of the data. Variations, fluctuations, and groupings (which often provide great insight) are lost. That’s not to say we shouldn’t average whole sets of data – this certainly has value – but other methods of slicing up and analyzing data are important to the understanding of what’s really going on.

We hope the new Supplemental Report sheds more light on the findings presented in the DBIR in ways that are helpful to your organization. Even if your industry is not included among the four discussed throughout the report, perhaps you can identify with certain characteristics of them or experience similar challenges in your business environment. At the very least, it should reinforce the notion that an efficient and effective information security program cannot be achieved through a standardized template applied without regard to the unique risks faced by each organization.

Perhaps, however, you’ve been approaching the question from the wrong perspective. Try asking yourself what you might NOT be able to do if you had a system completely devoid of any security. Would it work at all? The answer is probably not.

The problem has been that security has been an afterthought for far too long. Our thinking goes something like this: “What do I need to get done, and what should I buy to help me do it?” Historically, that’s where the questions end. This it typically true whether you were purchasing a new computer to roll out to your company or designing a new piece of software at Microsoft.

Again, what if you consider your requirements from a different perspective? Many years ago at MCI, I was contracted to be part of a team working with British Telecom and Microsoft. Our job was to try to create “hosted intranets.” If we hosted your servers and you could connect to them from anywhere, bingo, we’d have a huge seller (this was 1997, so it was a pretty brazen idea).

Anyway, my job was to be in charge of the security for the project. I was going to secure “Hosted Intranets.” Uh huh, ok…hmm…how??

If memory serves, our inaugural meeting for the project was at the Ritz-Carlton, Pentagon City. In a grand ballroom we brought all the teams together; those devoted to the hardware, the network, the software, and me. Every team had numerous members (except for mine). At some point we were told to prepare for a brief presentation. “Tell us what you’re going to do to get your part of the project over the finish line.” Given the fact that I had been hired for the job by Vint Cerf, I was feeling pretty intimidated. “What the heck am I going to say?”, I thought.

Well, eventually my turn arose, and I noticed Vint standing in the back of the room. I answered, “Me, well, I’m not going to do anything…you’re going to do my work for me.”

I went on to explain that there was nothing for me to do, but sit in on all of their meetings and ensure that they each considered all of the security aspects required for their components of the project. By designing security into the specifications, we could ensure there would be no holes anywhere that would later need to be filled. Networks needed firewalls and ACLs on routers, servers needed to be hardened or have functionality designated to different adapters each serving a different realm of connections, software needed to enforce authorization and authentication, etc.

Once the security was designed into the other components, the actual cost of security became zero. There was no security that was just there for security’s sake. It was present to augment, or support, some other feature of the whole. As each security requirement was introduced to the individual teams it was discussed both from the perspective of cost versus benefit, and operation versus function. Could we use a cheaper product? Could we do it with less security? Could we manage it with fewer people? In essence, we discussed all of the things you’d do if you were talking about a non-security component. After all, where’s the difference once you understand the feature’s need within the entire scheme of things?

For example, I don’t need authentication just for security’s sake, I can’t produce assured billing if I can’t back up my claims of your access, so authentication is as required to make money as it is to assure only your employees can access your Intranet. Try and identify a security feature that doesn’t have an operational function similar to this. You won’t be able to because they all do. I need AV to avoid the costly restoration of files on a file server, conversely, I need AV to ensure the availability of files on a file server. Call it semantics if you want, but the difference in wording means the difference between justifying ROI of AV versus justifying the ROI of file servers. It’s far easier to justify the cost of a file server with AV than it is to justify AV on its own.

Public Key Infrastructure (PKI) is another one of those security topics that suffers enormously due to the security ROI bunk. Introducing PKI can have significant up-front costs; however, when you realize that’s simply because you’ve probably been lacking in your infrastructure prior to it, you may find it can be much easier to justify the cost of PKI. Abuse of reusable passwords is probably one of the oldest, and most common, sources of breaches. Many have gone to tokens to avoid this problem (at no small cost I might add). More often than not it is because PKI was not well understood by the people entrusted to implement a new scheme, or because tokens appear cheaper than PKI up-front. It can also be due to the fact that tokens seem to be more easily bolted on to existing environments without having to make changes to that environment.

If you actually look closely at PKI, and talk to people who really know, you’ll soon see that an infrastructure that has PKI available has many more capabilities, yet have so much less modification and cost, than any other environment. Not only will you exceed all standards or regulations that might impose on you, but you’ll have the flexibility to do pretty much anything you want easily. So, with a minor perspective shift, you can view the costs of PKI not as standalone costs, but, more accurately, as an augmentation to the cost of your network, servers, desktops and software. You would also see that the minor increase is significantly offset by the reduced cost (and headache involved) in help desk, software maintenance and licensing.

Intrusion Detection/Prevention Systems are probably the most difficult to justify. Typically they do very little out of the box, and require an investment in training and deployment to provide much use. Not that this is terribly different from any other component of your environment, but they are so often not dealt with appropriately that, in the long run, they typically provide the least benefits versus cost. This doesn’t need to be the case, but for you not to fall into this common trap you have to fully appreciate the purpose of such tools, and know how you’re going to incorporate them into your regular operations. Having them managed by a third party is often more cost effective, as it helps you to avoid having to have trained personnel and maintain updates.

Whichever way you go, if you’ve considered the components functionality and operational requirements carefully, and decided it is a requirement of your environment then its cost is merely another add-on to the whole.

So now the problem becomes “How do I get these new infrastructure components if I have to justify them using the cost of the entire environment?”

Well, the answer to this is fairly obvious. You need to revalue your environment and show how, without these components, the risk you’re presented with outweighs the cost of bringing it up to snuff. In other words, show how the costs in the future are going to be reduced due to the increased capabilities of the network. You won’t have to purchase something to comply with a new regulation; you’ll simply be implementing some new aspect of your PKI. Since new deployments of PCs will incorporate a swath of security features such as AV, client-side certificates, and other agents, the management and maintenance of those PCs will be easier. Audits will be cheaper because you’ll have a far better understanding of what exists, where the transaction zones are, and how they’re being managed securely.

So while it is a very old adage, its time for you to build security into your environment rather than try to bolt it on, and get everyone to agree to forget about security ROI.