“Security requires a particular mindset. Security professionals — at least the good ones — see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.”
- Bruce Schneier

For me, acquiring a “security” mindset wasn’t tough.  I was lucky enough to work with some great penetration testers.  The whole “social engineering” thing was easy to “get”, too.  By my second engagement, I acquired a love for figuring out how to manipulate the denigrated bureaucracy.

The problem with the security mindset is that, in risk analysis, it carries over as a bias.  When I’m out training organizations, there’s usually a really smart guy with ages of cybercop experience who will devolve the conversation about Vulnerability (Threat Capability vs. our Controls) into how he would use his knowledge of the systems and their weaknesses to possibly steal millions and millions of dollars/identities/trade secrets/whatever in a particularly clever way.  It happens every session.  It’s not a bad thing - but it has to be qualified within the context of the applicable threat community.  Are we really worried about an uber-brilliant admin with 20 years at the company and intimate knowledge of the systems architecture as a threat community?  Maybe we are, and if so this is a great and relevant discussion.

But if we’re not able to throw the resources at a problem needed to address someone whose skills and resources are in the top 1/10 of 1% of the threat community out there, what we’ve done is had a rabbit trail conversation that *if* an attacker had near perfect knowledge of the system and it’s defenses, it would be possible to evade prevention, detection, and most likely response until it was too late.  Great, but there’s a bias there that we’re carrying into the discussion because of the security mindset.

Thing is, once the security mindset matures with experience, we *know* that it is possible, for any system, regardless of physical location or vendors that supply software, to be compromised.  The question the risk analyst must answer, however, is really “What is *probable*?”.   And we should really belabor the point that “What is probable?” is not just a “Can it be done?” question. Yes, Level of Effort or Skills & Resources are relevant pieces of prior information, but what is similarly (if not more) important is the concept of frequency of events - or “*Is* it being done or more likely to be done in the future, and at what rate?”

EXAMPLE OF THE DIFFERENCE

There should probably be a Godwin-esque law about 9/11 examples and security by now, but you’ll forgive the indulgence.  Post 9/11, we had all sorts of questions about the risk of attackers and national infrastructure.  And the reason isn’t because we couldn’t imagine all sorts of creative attacks against nuclear power plants, metropolitan water supplies or large visibility entertainment venues.  Our uncertainty was due to a perceived possibility in an increase in frequency.  They did something spectacular once, (when) will they do it again?

This should be the mindset of the risk analyst.  Understand that it can be done, and how it may be accomplished, to be sure.  But it’s imperative that we frame that knowledge within the context of frequency and impact considerations.

For me, the good news is that mindests don’t seem to be fixed.  Training analysts in FAIR has shown me that they can be learned and unlearned.  In fact, I’m starting to think that a sign of IQ/EQ/Whatever might be said to be the speed with which one may adopt other mindsets.

Relevant References:

http://www.bloginfosec.com/2008/04/10/the-misleading-nature-of-schneiers-security-mindset/

http://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html

Talk to the exhibitors, though, and the most common complaint is that the attendees aren't buying.

It's not the quality of the wares. The show floor is filled with new security products, new technologies, and new ideas. Many of these are products that will make the attendees' companies more secure in all sorts of different ways. The problem is that most of the people attending the RSA Conference can't understand what the products do or why they should buy them. So they don't.

I spoke with one person whose trip was paid for by a smallish security firm. He was one of the company's first customers, and the company was proud to parade him in front of the press. I asked him if he walked through the show floor, looking at the company's competitors to see if there was any benefit to switching.

"I can't figure out what any of those companies do," he replied.

I believe him. The booths are filled with broad product claims, meaningless security platitudes, and unintelligible marketing literature. You could walk into a booth, listen to a five-minute sales pitch by a marketing type, and still not know what the company does. Even seasoned security professionals are confused.

Commerce requires a meeting of minds between buyer and seller, and it's just not happening. The sellers can't explain what they're selling to the buyers, and the buyers don't buy because they don't understand what the sellers are selling. There's a mismatch between the two; they're so far apart that they're barely speaking the same language.

This is a bad thing in the near term -- some good companies will go bankrupt and some good security technologies won't get deployed -- but it's a good thing in the long run. It demonstrates that the computer industry is maturing: IT is getting complicated and subtle, and users are starting to treat it like infrastructure.

For a while now I have predicted the death of the security industry. Not the death of information security as a vital requirement, of course, but the death of the end-user security industry that gathers at the RSA Conference. When something becomes infrastructure -- power, water, cleaning service, tax preparation -- customers care less about details and more about results. Technological innovations become something the infrastructure providers pay attention to, and they package it for their customers.

No one wants to buy security. They want to buy something truly useful -- database management systems, Web 2.0 collaboration tools, a company-wide network -- and they want it to be secure. They don't want to have to become IT security experts. They don't want to have to go to the RSA Conference. This is the future of IT security.

You can see it in the large IT outsourcing contracts that companies are signing -- not security outsourcing contracts, but more general IT contracts that include security. You can see it in the current wave of industry consolidation: not large security companies buying small security companies, but non-security companies buying security companies. And you can see it in the new popularity of software as a service: Customers want solutions; who cares about the details?

Imagine if the inventor of antilock brakes -- or any automobile safety or security feature -- had to sell them directly to the consumer. It would be an uphill battle convincing the average driver that he needed to buy them; maybe that technology would have succeeded and maybe it wouldn't. But that's not what happens. Antilock brakes, airbags, and that annoying sensor that beeps when you're backing up too close to another object are sold to automobile companies, and those companies bundle them together into cars that are sold to consumers. This doesn't mean that automobile safety isn't important, and often these new features are touted by the car manufacturers.

The RSA Conference won't die, of course. Security is too important for that. There will still be new technologies, new products, and new start-ups. But it will become inward-facing, slowly turning into an industry conference. It'll be security companies selling to the companies who sell to corporate and home users -- and will no longer be a 17,000-person user conference.

This essay originally appeared on Wired.com.

Talk to the exhibitors, though, and the most common complaint is that the attendees aren't buying.

It's not the quality of the wares. The show floor is filled with new security products, new technologies, and new ideas. Many of these are products that will make the attendees' companies more secure in all sorts of different ways. The problem is that most of the people attending the RSA Conference can't understand what the products do or why they should buy them. So they don't.

I spoke with one person whose trip was paid for by a smallish security firm. He was one of the company's first customers, and the company was proud to parade him in front of the press. I asked him if he walked through the show floor, looking at the company's competitors to see if there was any benefit to switching.

"I can't figure out what any of those companies do," he replied.

I believe him. The booths are filled with broad product claims, meaningless security platitudes, and unintelligible marketing literature. You could walk into a booth, listen to a five-minute sales pitch by a marketing type, and still not know what the company does. Even seasoned security professionals are confused.

Commerce requires a meeting of minds between buyer and seller, and it's just not happening. The sellers can't explain what they're selling to the buyers, and the buyers don't buy because they don't understand what the sellers are selling. There's a mismatch between the two; they're so far apart that they're barely speaking the same language.

This is a bad thing in the near term -- some good companies will go bankrupt and some good security technologies won't get deployed -- but it's a good thing in the long run. It demonstrates that the computer industry is maturing: IT is getting complicated and subtle, and users are starting to treat it like infrastructure.

For a while now I have predicted the death of the security industry. Not the death of information security as a vital requirement, of course, but the death of the end-user security industry that gathers at the RSA Conference. When something becomes infrastructure -- power, water, cleaning service, tax preparation -- customers care less about details and more about results. Technological innovations become something the infrastructure providers pay attention to, and they package it for their customers.

No one wants to buy security. They want to buy something truly useful -- database management systems, Web 2.0 collaboration tools, a company-wide network -- and they want it to be secure. They don't want to have to become IT security experts. They don't want to have to go to the RSA Conference. This is the future of IT security.

You can see it in the large IT outsourcing contracts that companies are signing -- not security outsourcing contracts, but more general IT contracts that include security. You can see it in the current wave of industry consolidation: not large security companies buying small security companies, but non-security companies buying security companies. And you can see it in the new popularity of software as a service: Customers want solutions; who cares about the details?

Imagine if the inventor of antilock brakes -- or any automobile safety or security feature -- had to sell them directly to the consumer. It would be an uphill battle convincing the average driver that he needed to buy them; maybe that technology would have succeeded and maybe it wouldn't. But that's not what happens. Antilock brakes, airbags, and that annoying sensor that beeps when you're backing up too close to another object are sold to automobile companies, and those companies bundle them together into cars that are sold to consumers. This doesn't mean that automobile safety isn't important, and often these new features are touted by the car manufacturers.

The RSA Conference won't die, of course. Security is too important for that. There will still be new technologies, new products, and new start-ups. But it will become inward-facing, slowly turning into an industry conference. It'll be security companies selling to the companies who sell to corporate and home users -- and will no longer be a 17,000-person user conference.

This essay originally appeared on Wired.com.

For review, you can look up our previous entries here:

Part 1
Part 2
Part 3
Part 4
Part 5

Define Needs

Before you start looking at any tools, you need to understand why you might need DAM how you plan on using it, and the business processes around management, policy creation, and incidents handling.

Create a selection committee: Database Activity Monitoring programs tend to involve four major technical stakeholders , and one or two non-technical business units. On the technical side it’s important to engage the database and application administrators with systems that may be within the scope of the project over time, not just the one database and/or application you plan on starting with. Although many DAM projects start with a limited scope, they can quickly grow into enterprise-wide programs. Security and the database team are typically the main drivers of a project, and the office of the CIO is often involved due to compliance needs or to mediate cross-team issues. On the non-technical side, you should have representatives from audit, and compliance and risk (if they exist in your organization). Once you identify the major stakeholders, you’ll want to bring representatives together into a selection committee.

Define the systems and platforms to protect: DAM projects are typically driven with a clear audit or security goal tied to particular systems, applications, or databases. In this stage, detail the scope of what will be protected and the technical specifics of the platforms involved. You’ll use this list to determine technical requirements and prioritize features and platform support later in the selection process. Remember that your needs will grow over time, so break the list into a group of high priority systems with immediate needs, and a second group summarizing all major platforms you may need to protect at a later time.

Determine protection and compliance requirements: For some systems you might want strict preventative security controls, while for others you may just need comprehensive activity monitoring for a compliance requirement. In this step you map your protection and compliance needs to the platforms and systems from the previous step. This will help you determine everything from technical requirements to process workflow.

Outline process workflow and reporting requirements: Database Activity Monitoring workflow tends to vary based on the use case involved. When used as an internal control for separation of duties, security will monitor and manage events and have an escalation process should database administrators violate policy. When used as an active security control, the workflow may more actively engage security and database administration as partners in managing incidents. In most cases, audit, legal, or compliance will have at least some sort of reporting role. Since different DAM tools have different strengths and weaknesses in terms of management interfaces, reporting, and internal workflow, knowing your process before defining technical requirements can prevent headaches down the road.

By the completion of this phase you should have defined key stakeholders, convened a selection team, prioritized the systems you want to protect, determined protection requirements, and roughed out workflow needs.

Formalize Requirements

This phase can be performed by a smaller team working under the mandate of the selection committee. Here, the generic needs determined in phase 1 are translated into specific technical features, while any additional requirements are considered. This is the time to come up with any criteria for directory integration, additional infrastructure integration, data storage, hierarchical deployments, change management integration, and so on. You can always refine these requirements after you proceed to the selection process and get a better feel for how the products work.

At the conclusion of this stage you develop a formal RFI (Request For Information) to release to vendors, and a rough RFP (Request For Proposals) that you’ll clean up and formally issue in the evaluation phase.

Evaluate Products

As with any products, it’s sometimes difficult to cut through marketing materials and figure out if a product really meets your needs. The following steps should minimize your risk and help you feel confident in your final decision:

Issue the RFI: Larger organizations should issue an RFI though established channels and contact a few leading DAM vendors directly. If you’re a smaller organization, start by sending your RFI to a trusted VAR and email a few of the DAM vendors which seem appropriate for your organization.

Perform a paper evaluation: Before bringing anyone in, match any materials from the vendor or other sources to your RFI and draft RFP. Your goal is to build a short list of 3 products which match your needs. You should also use outside research sources and product comparisons.

Bring in 3 vendors for an on-site presentation and demonstration: Instead of a generic demonstration, ask the vendors to walk you through specific use cases that match your expected needs. Don’t expect a full response to your draft RFP; these meetings are to help you better understand the different options out there and eventually finalize your requirements.

Finalize your RFP and issue it to your short list of vendors: At this point you should completely understand your specific requirements and issue a formal, final RFP.

Assess RFP responses and begin product testing: Review the RFP results and drop anyone who doesn’t meet any of your minimal requirements (such as platform support), as opposed to “nice to have” features. Then bring in any remaining products for in-house testing. You’ll want to replicate your highest volume system and the corresponding traffic, if at all possible. Build a few basic policies that match your use cases, then violate them, so you can get a feel for policy creation and workflow.

Select, negotiate, and buy: Finish testing, take the results to the full selection committee, and begin negotiating with your top choice.

Internal Testing

• Platform support and installation to determine compatibility with your database/application environment. This is the single most important factor to test, including monitoring coverage for the connection methods used in your organization, since different database platforms support a variety of connection types.
• Performance- is network or agent performance acceptable for you environment? Don’t set arbitrary standards; monitor performance on your production systems to make sure testing represents operational requirements.
• Policy creation and management. Create policies to understand the process and complexity. Do you need to write everything as SQL? Will pre-built policies meet your needs? Are there wizards and less-technical options for non-database experts to create policies? Then violate policies and try to evade or overwhelm the tool to learn where its limits are.
• Incident workflow — Review the working interface with those employees who will be responsible for enforcement.
• Behavioral profiling, if the product supports that as a way of developing policies.
• Directory integration.
• Change management integration.
• Enforcement/blocking/rollback and other advanced features.

Technorati Tags: ADMP, Database Activity Monitoring, Tools, Tutorial

I replied: "What's really interesting is that these people will send a tube of live ants to anyone you tell them to."

Security requires a particular mindset. Security professionals -- at least the good ones -- see the world differently. They can't walk into a store without noticing how they might shoplift. They can't use a computer without wondering about the security vulnerabilities. They can't vote without trying to figure out how to vote twice. They just can't help it.

SmartWater is a liquid with a unique identifier linked to a particular owner. "The idea is for me to paint this stuff on my valuables as proof of ownership," I wrote when I first learned about the idea. "I think a better idea would be for me to paint it on your valuables, and then call the police."

Really, we can't help it.

This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don't have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems.

I've often speculated about how much of this is innate, and how much is teachable. In general, I think it's a particular way of looking at the world, and that it's far easier to teach someone domain expertise -- cryptography or software security or safecracking or document forgery -- than it is to teach someone a security mindset.

Which is why CSE 484, an undergraduate computer-security course taught this quarter at the University of Washington, is so interesting to watch. Professor Tadayoshi Kohno is trying to teach a security mindset.

You can see the results in the blog the students are keeping. They're encouraged to post security reviews about random things: smart pill boxes, Quiet Care Elder Care monitors, Apple's Time Capsule, GM's OnStar, traffic lights, safe deposit boxes, and dorm room security.

One recent one is about an automobile dealership. The poster described how she was able to retrieve her car after service just by giving the attendant her last name. Now any normal car owner would be happy about how easy it was to get her car back, but someone with a security mindset immediately thinks: "Can I really get a car just by knowing the last name of someone whose car is being serviced?"

The rest of the blog post speculates on how someone could steal a car by exploiting this security vulnerability, and whether it makes sense for the dealership to have this lax security. You can quibble with the analysis -- I'm curious about the liability that the dealership has, and whether their insurance would cover any losses -- but that's all domain expertise. The important point is to notice, and then question, the security in the first place.

The lack of a security mindset explains a lot of bad security out there: voting machines, electronic payment cards, medical devices, ID cards, internet protocols. The designers are so busy making these systems work that they don't stop to notice how they might fail or be made to fail, and then how those failures might be exploited. Teaching designers a security mindset will go a long way toward making future technological systems more secure.

That part's obvious, but I think the security mindset is beneficial in many more ways. If people can learn how to think outside their narrow focus and see a bigger picture, whether in technology or politics or their everyday lives, they'll be more sophisticated consumers, more skeptical citizens, less gullible people.

If more people had a security mindset, services that compromise privacy wouldn't have such a sizable market share -- and Facebook would be totally different. Laptops wouldn't be lost with millions of unencrypted Social Security numbers on them, and we'd all learn a lot fewer security lessons the hard way. The power grid would be more secure. Identity theft would go way down. Medical records would be more private. If people had the security mindset, they wouldn't have tried to look at Britney Spears' medical records, since they would have realized that they would be caught.

There's nothing magical about this particular university class; anyone can exercise his security mindset simply by trying to look at the world from an attacker's perspective. If I wanted to evade this particular security device, how would I do it? Could I follow the letter of this law but get around the spirit? If the person who wrote this advertisement, essay, article or television documentary were unscrupulous, what could he have done? And then, how can I protect myself from these attacks?

The security mindset is a valuable skill that everyone can benefit from, regardless of career path.

This essay originally appeared on Wired.com.

I replied: "What's really interesting is that these people will send a tube of live ants to anyone you tell them to."

Security requires a particular mindset. Security professionals -- at least the good ones -- see the world differently. They can't walk into a store without noticing how they might shoplift. They can't use a computer without wondering about the security vulnerabilities. They can't vote without trying to figure out how to vote twice. They just can't help it.

SmartWater is a liquid with a unique identifier linked to a particular owner. "The idea is for me to paint this stuff on my valuables as proof of ownership," I wrote when I first learned about the idea. "I think a better idea would be for me to paint it on your valuables, and then call the police."

Really, we can't help it.

This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don't have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems.

I've often speculated about how much of this is innate, and how much is teachable. In general, I think it's a particular way of looking at the world, and that it's far easier to teach someone domain expertise -- cryptography or software security or safecracking or document forgery -- than it is to teach someone a security mindset.

Which is why CSE 484, an undergraduate computer-security course taught this quarter at the University of Washington, is so interesting to watch. Professor Tadayoshi Kohno is trying to teach a security mindset.

You can see the results in the blog the students are keeping. They're encouraged to post security reviews about random things: smart pill boxes, Quiet Care Elder Care monitors, Apple's Time Capsule, GM's OnStar, traffic lights, safe deposit boxes, and dorm room security.

One recent one is about an automobile dealership. The poster described how she was able to retrieve her car after service just by giving the attendant her last name. Now any normal car owner would be happy about how easy it was to get her car back, but someone with a security mindset immediately thinks: "Can I really get a car just by knowing the last name of someone whose car is being serviced?"

The rest of the blog post speculates on how someone could steal a car by exploiting this security vulnerability, and whether it makes sense for the dealership to have this lax security. You can quibble with the analysis -- I'm curious about the liability that the dealership has, and whether their insurance would cover any losses -- but that's all domain expertise. The important point is to notice, and then question, the security in the first place.

The lack of a security mindset explains a lot of bad security out there: voting machines, electronic payment cards, medical devices, ID cards, internet protocols. The designers are so busy making these systems work that they don't stop to notice how they might fail or be made to fail, and then how those failures might be exploited. Teaching designers a security mindset will go a long way toward making future technological systems more secure.

That part's obvious, but I think the security mindset is beneficial in many more ways. If people can learn how to think outside their narrow focus and see a bigger picture, whether in technology or politics or their everyday lives, they'll be more sophisticated consumers, more skeptical citizens, less gullible people.

If more people had a security mindset, services that compromise privacy wouldn't have such a sizable market share -- and Facebook would be totally different. Laptops wouldn't be lost with millions of unencrypted Social Security numbers on them, and we'd all learn a lot fewer security lessons the hard way. The power grid would be more secure. Identity theft would go way down. Medical records would be more private. If people had the security mindset, they wouldn't have tried to look at Britney Spears' medical records, since they would have realized that they would be caught.

There's nothing magical about this particular university class; anyone can exercise his security mindset simply by trying to look at the world from an attacker's perspective. If I wanted to evade this particular security device, how would I do it? Could I follow the letter of this law but get around the spirit? If the person who wrote this advertisement, essay, article or television documentary were unscrupulous, what could he have done? And then, how can I protect myself from these attacks?

The security mindset is a valuable skill that everyone can benefit from, regardless of career path.

This essay originally appeared on Wired.com.

Virus from China, the gift that keeps on giving

An insidious computer virus recently discovered on digital photo frames has been identified as a powerful new Trojan Horse from China that collects passwords for online games -- and its designers might have larger targets in mind.

"It is a nasty worm that has a great deal of intelligence," said Brian Grayek, who heads product development at Computer Associates, a security vendor that analyzed the Trojan Horse... The authors of the new Trojan Horse are well-funded professionals whose malware has "specific designs to capture something and not leave traces," Grayek said. "This would be a nuclear bomb" of malware.

Mocmex is its name. Reportedly, it can evade hundreds of anti-malware and firewall products, including the Windows Firewall. I suspect that this succeeds only when users are logged in as administrators, so here's yet another reason to stop doing this altogether, as is the US Government with its new Federal Desktop Core Configuration for Windows XP and Windows Vista.

The virus actually propagates to just about any kind of removable USB storage device, jumping from various well-concealed hiding places on your PC whenever such a device is inserted. Picture frames are implicated because the virus apparently originated in the factory where the frames were built (in turn sold by Best Buy, Sam's Club, Target, and Costco, but now discontinued). Amazingly, according to the UK security firm Prevx, over 67,500 variants of this thing exist!

Even more amazing:

[Mocmex] isn't the only piece of malware involved. Deborah Hale of Sans said the researchers also found four other, older Trojans on each frame, which may serve as markers for botnets -- networks of infected PCs that are remotely controlled by hackers.

There is W32.Rajump, which deposits the same piece of malware that infected some of Apple's video iPods during manufacturing in October 2006. It gathers IP addresses and port numbers from infected PCs and ships them out, according to Symantec. One destination is registered to a service in China that allows people to conceal their own IP addresses.

Then there is a generic Trojan; a Trojan that opens a back door on PCs and displays pop-up ads; and a Trojan that spreads itself through portable devices like Mocmex does.

More reasons to disable Autorun, I suppose. Yet this isn't a cure-all: if you're logged in as administrator, the virus helpfully re-enables Autorun. Sheesh! If you own one of these frames, SANS suggests that you take it to a friend who has a Mac or Linux box and plug it in there. Yeah, that's good advice; there exist no viruses for these operating systems, correct? It's irrelevant which operating system you're using -- if you run with full privileges, you'll get 0wn3d soon enough.

It's fascinating that the thing targets online games, although it could certainly harvest just about any private information stored on your PC. Mining online game accounts might be pretty profitable, you know. Consider the number of people who pay real money for virtual (=fake) stuff in World of Warcraft, Runescape, and whatever else. I suppose losing their passwords to picture frames might help such people regain a tenuous foothold on reality.