Security Strategies – January 31, 2002

Why Check Point should buy RSA

By: Pete Lindstrom, Director — Reply to:plindstrom@hurwitz.com [not active anymore]

It is no secret that the security space is highly fragmented. Hundreds of companies vie for market share and mindshare amidst hundreds of others, all with a bit of a unique spin – operating within the Four Disciplines of security management (Identity, Configuration, Threat, and Trust Management). Even within Operational Security (Authentication, Access Control) choices and configurations abound. There is no true “security” company because there is so much to do and so many ways to do it.

THE HURWITZ TAKE

The company that can consolidate solutions and provide broad coverage in the areas described above will own the security market. But who will that be? Right now, Symantec has a strong story in the Threat Management and Configuration Management space, with ISS close behind. Tivoli has a strong presence in Access Control and is working on mindshare in Identity Management and Threat Management. Netegrity and Verisign have interesting plays in Access Control and Trust Management, respectively. CA has products in just about all of these areas, but no solid mindshare. That leaves Check Point and RSA.

Check Point and RSA – at its most basic level, there doesn’t seem to be too much in common. But a second look reveals plenty of similarities, in both their businesses and solutions:

n Both Check Point and RSA own the markets and the minds in firewalls and authentication, respectively.

n Both have strong indirect channels. In fact, they share many of the same resellers.

n There are two basic prerequisites to selling a security solution – if you support authentication, you must support RSA’s SecurID; if you have a network security solution, you must join Check Point’s OPSEC Alliance.

n Check Point provides Access Control at the network layer. RSA provides Authentication at the network and application layers. Authentication and access control are always linked, with the common denominator for networks being the VPN.

But wait, there’s more. From that position, they could roll up the authentication space by adding biometrics and dedicating effort toward smart cards and single sign-on (with RSA’s RADIUS server). They can take the Securant solution that RSA acquired and integrate it with firewalls –increasingly important in the continual blend of the network and application layers.

There are other reasons to consider this, but the end result is the same: A Check Point – RSA merger would result in an operational security powerhouse that could own and define the security space in years to come.

This type of thing goes on all the time among friends – it is juvenile humor at its finest. But it makes me (mildly) uncomfortable to read something like this. I guess I can't understand how someone who respects privacy so much could violate someone else's so easily.

I believe the core issues of privacy revolve around loss of control and misperception. This has both.

I find it even more interesting to consider the outcome of exercises like this on a broader scale – let's say many people start doing this many times… assuming there are also many who value authenticity, it only increases the demand for a national ID program.

More importantly, we don't really have to predict SSNs, because they aren't secret. In a typical lifetime, over 150,000 people will have legitimate access to your SSN (my estimate). No need for predictions, it is just available information.

Treating SSNs as secrets is part of our ongoing identity crisis.

More:
A Modest Proposal to Eliminate the SSN Façade
Is the SSN a good identifier?
SSNs Re-Re-Re-Revisited

So, the goal was a simple one, and it is clear that there is no overarching structure to the metrics, but I think it is useful to see what metrics were top-of-mind at the session. Here are the ones we came up with (and discussed) during the session:

% of Managers that Certify User Roles

Number of Password Resets

Cost per Password Reset

Number of Failed Logins

Number of Stale Accounts

Dead but Active Accounts

Login Spoof Attempts

Avg Time to Provision

Number of Privileged User Accounts

Number of VPN Connections per Week

User Account Growth Rate

% Systems Patched {OS; Platform use}

% Bandwidth Change

Number of Viruses

Avg Time to Recover

Avg Vulns per Host

Number of Applications

Number of Ports Open

Number of Servers

Number of Desktops

% of Systems with AV Installed {turned on;
up-to-date}

Number of Exploitable Vulns

% of Security-related Defects

Avg Time to Find Vulns

Incidents per Month

I am not a fan of some of these metrics, but they are interesting nonetheless. I hope to find time to analyze them further in the future.

The resulting maturity of the security market creates a situation where thinking in terms of product categories becomes increasingly difficult as any new category feels vaguely familiar and existing categories extend into adjacent territory. In short, we spend a lot of time getting better at what we are doing, adapting to new technology, and improving deployment options more than we are fundamentally changing the rules of the security game.

It may be useful to have a set of "atomic security functions" that act as building blocks so that all other solutions can be shown to be combinatorial or derivative of these functions. All of these functions are inline – between source consumer and target provider.

Here's a start:

1. Authenticate
   • source (e.g. user | machine | program | message)
   • destination
2. Filter
   • source (e.g. access control based on source identity)
   • destination
   • traffic characteristics (non-deterministic)
3. Obfuscate (e.g. encrypt, usually)
4. Validate (e.g. check integrity of program | data | content)
5. Monitor (I am not convinced this one belongs, but have included it given our propensity to monitor. I think in the end, this is really another form of filter.)

I am not convinced this list is complete for inline functionality, so please feel free to offer up your own. When you think about it, it can be surprisingly difficult to factor out what we think we know about security functions, especially in the face of existing mature product categories.

1. "IE Protected Mode, while not a true defendable security boundary" So what exactly is a true defendable security boundary, and why doesn't IE protected mode fit the bill? Are there other examples of truly defendable security boundaries out there?
2. "As security through obscurity does not exist" What's your password again? and your firewall configuration? And does security without obscurity exist?
3. "Shouldn’t the MBTA be suing the vendor who sold them the flawed system?" Hmmm, I don't know – is there such thing as a perfect (non-flawed) system?

The Guardian had an article yesterday about how vulnerability auctions are essentially protection rackets and it is all bad for security:

This year computer users will be more exposed to
cybercriminals than ever before. It’s not just because online crime is so
attractive to identity theft gangs but, ironically, because the computer
security industry that is supposed to protect users has deteriorated – from one
which shared everything about newly discovered weaknesses to what some within
it now call a "protection racket".

…

"The security industry is fast becoming a protection
racket. There’s no other word for it," Henry says. "The tradition has
always been for vendors to share information on vulnerabilities so we can all
protect our customers. Now you’ve got hackers being given a so-called
legitimate route of selling vulnerabilities to a single company who then
protect their own.

People love certainty, even when the knowledge may increase the risk, which it does with broader disclosure. You see, the vulnerability already exists in your environment, so you have already accepted that risk. The only thing that changes the equation, then, is the threat side – and more people knowing about it equals greater threat, and therefore increased risk.

Mitigation techniques that are tied to specific knowledge of specific vulnerabilities (e.g. patches) are inherently flawed. The benefit is greatly outweighed by the cost, when you look at a) the proportional allocation of resources across ALL vulnerabilities (including unidentified ones) in an environment, and b) the number of vulnerabilities that are actually exploited.

Ask yourself this question: why do would you think bugfinders are finding ALL of the exact same vulnerabilities that the bad guys are finding and using? There are so many vulnerabilities to choose from, the "collision" rate could easily be very low (and is low, according to security professionals who subscribe to the belief that the black hats are winning). In order to be sufficient, an explicit discovery strategy must find every vulnerability.

The industry must either increase vulnerability discovery by (probably) a factor of 10x or more to even attempt to catch up with every single vulnerability ever created and being created in real-time…. or come up with new methods for protection.

For further reading, see my original post on vulnerability auctions.

This occurred to me when I read a
prediction that by the middle of this year this would be the case [at least I think that was the prediction, and I can't find it right now - please forward to me if you find it. thanks.]

I don’t recall any discussion about this, and I think it is trickier than it sounds. I inferred from the point that this was entirely "A Bad Thing" but that is not obvious to me. It seems like it would be in the best interest of anyone who has had their SSNs stolen to hope for more of the same, in an attempt to reduce their own risk of fraud (because there are more identities to choose from). Of course, this assumes that there is some satiating level for fraudulent activity.

I think the real question may be one of supply and demand – are there enough SSNs out there to meet the demand from buyers/perpetrators, or not? If yes, then the assumption holds and I think the overall risk reaches some sort of equilibrium point. If not, then everyone’s risk may have slightly increased.

Update: Links to previous posts on this topic.

- Estimate the number of people with defendable access to your SSN here.

- Learn about why we should just publish all SSNs and get it over with here.

Dark Reading: Insecure Software Costs US $180B per Year, according to David Rice in his book, Geekonomics. [Me: I wonder how he came up with that?]

Here’s the nut graph from the Dark Reading article:

He estimates that the actual cost of insecure software to
the U.S. is at least $180 billion per year, although he acknowledges
that such numbers are "soft." He based his estimates on other numbers
– including a recent General Accounting Office report that says the
U.S. cybercrime market is around $117 billion — as well as other
reports, such as estimates of worldwide phishing operations of $350
billion per year.

Here’s the pertinent part of his book (p. 37):

In the case of software, the National Institute of Standards and Technology (NIST) the cost of inadequate software testing cost the United States roughly $60 billion, which is just under 1% of GDP. This cost does not account for other social costs associated with software usage such as cyber crime and related identity theft, however. A 2007 report by the Government Account [sic] Office (GAO) estimated cyber crime costs the U.S. economy approximately $117 billion a year.

Given that $117 and $60 make $177 ~ $180 billion, I am going to assume these are the sources the DR article (and other parts of the book) reference:

1. The NIST study in 2002, which was actually done under contract by RTI: Economic Impacts of Inadequate Infrastructure for Software Testing.
2. The $117 billion estimate, which actually comes from an article written about the GAO report in E-commerce Times: Cybercrime Costs US Economy at Least $117B Each Year. The GAO report itself is available as well: Cybercrime: Public and Private Entities Face Challenges in Addressing Cyber Threats.

Though I’ve been known to employ my own back-of-the-envelope estimates on occasion, I have a number of reservations about the approach employed by Geekonomics:

1. The RTI study employed interview techniques and included all faults, not just security-related ones. In addition, the estimate was actually a range from a "feasible" $23 billion to the $60 billion identified in the book.
2. The GAO report is all secondary research; it simply aggregates the information from other studies. The $117 billion amount was derived from 3 of the identified reports totaled together. One main source for the $117 billion ($67.2 billion) was the 2005 FBI Computer Crime Survey. This survey includes, for example, losses associated with laptop/PDA theft that were not caused by "insecure" software.
3. The second largest report cited by the GAO is an identity theft report that cites $49.3 billion in losses. Unfortunately, the full report costs $2500 so I could only work with press reports. In any case, to source identity theft of all types back to insecure software is a huge leap. In at least one account (the "consumer version") only 2% of the incidents are Internet-related.
4. Btw, I believe all of these numbers (certainly most of them) are for the U.S. only.

I don’t know if this number is too high or too low, but I do know that this estimate doesn’t get us any closer to knowing the true cost of insecure software.