Login  |  Register  |  Contact
Tuesday, May 18, 2010

Understanding and Selecting SIEM/LM: Business Justification

By Mike Rothman

It’s time to resume our series on Understanding and Selecting a SIEM/Log Management solution. We have already discussed what problems this technology solves, with Use Cases 1 & Use Cases 2, but that doesn’t get a project funded. Next we need to focus on making the business case for the project and examine how to justify the investment in bean counter lingo.

End User Motivations and Business Justification

Securosis has done a lot of work on the motivation for security investments. Unfortunately our research shows budgets are allocated to visceral security issues people can see and feel, rather than being based on critical consideration of risks to the organization. In other words, it’s much harder to get the CEO to sign off on a six-figure investment when you can’t directly demonstrate a corresponding drop in profit or an asset loss. Complicating matters in many cases, such as the theft of a credit card, it’s someone else who suffers the loss. Thus compliance and/or regulation is really the only way to justify investments to address the quiet threats.

The good news relative to SIEM and Log Management is the technology is really about improving efficiency by enhancing the ability to deal with the mushrooming amount of data generated by network and security devices. Or being able to detect an attack designed to elude a firewall or IPS (but not both). Or even making reporting and documentation (for compliance purposes) more efficient. You can build a model to show improved efficiency, so of all security technologies - you’d figure SIEM/Log Management would be pretty straight forward to justify.

Of course, putting together a compelling business justification does not always result in a funded project. Remember when money gets tight (and when is money not tight?) sometimes it’s easier to flog employees to work harder, as opposed to throwing high dollar technology at the problem. Yes, the concept of automation is good, but quantifying the real benefits can be challenging.

Going Back to the Well

Our efforts are also hamstrung by a decade of mis-matched expectations relative to security spending. Our finance teams have seen it all, and in lots of cases haven’t seen the tangible value of the security technology. So they are justifiably skeptical relative to yet another ROI model showing a two week payback on a multi-million dollar investment. Yes, that’s a bit facetious, but only a bit.

When justifying any investment, we need to ensure not to attempt to measure what can’t be accurately measured, which inevitably causes the model to collapse under its own cumbersome processes and assumptions. We also need to move beyond purely qualitative reasoning, which produces hard to defend results. Remember that security is an investment that produces neither revenue nor fully quantifiable results, thus trying to model it is asking for failure.

Ultimately having both bought and sold security technology for many years, we’ve come to the conclusion that end user motivations can be broken down pretty simply into two buckets: Save Money or Make Money. Any business justification needs to very clearly show the bean counters how the investment will either add to the top line or help improve the bottom line. And that argument is far more powerful than eliminating some shadowy threat that may or may not happen.

Although depending on the industry, implementing log management (in some form) is not optional. There are regulations (namely PCI) that specifically call out the need to aggregate, parse and analyze log files. So the point of justification becomes what kind of infrastructure is needed, at what level of investment – since solutions range from free to millions of dollars. To understand where our economic levers are as we build the justification model, we need to get back to the use cases (Part 1, Part 2), and show how these can justify the SIEM/Log Management investments. We’ll start with the two use cases, which are pretty straight forward to justify because there are hard costs involved.

Compliance Automation

The reality is most SIEM/Log Management projects come from the compliance budget. Thus _compliance automation is a “must do” business justification because regulatory or compliance requirements must be met. These are not options. For example, if your board of directors mandates new Sarbanes-Oxley controls, you are going to implement them. If your business accepts credit cards on Internet transactions, you are going to comply with PCI data security standard.

But how to you justify a tool to make the compliance process more efficient? Get our your stop watch and start tracking the time it takes you to prepare for these audits. Odds are you know how long it took to get ready for your last audit, the auditor is going to continue looking over your shoulder – asking for more documentation on policies, processes, controls and changes.

The business case is based on the fact that the amount of time it takes to prepare for the audit is going to continue going up and you need automation to keep those costs under control. Whether the audit preparation budget gets allocated for people or tools shouldn’t matter. So you pay for SIEM/Log Management with the compliance budget, but the value accrues to both the security function and streamlines operations. Sounds like a win/win to us.

Operational Efficiency

Our next use case is about improving efficiency and this is relatively straightforward to justify. If you look back at the past few years, the perimeter defenses of your organization have expanded significantly. This perimeter sprawl is due to purpose-built devices being implemented to address specific attack vectors. Think email gateway, web filter, SSL VPN, application aware firewall, web application firewall, etc. All of which have a legitimate place in a strong perimeter. Specifically each device requires management to set policies, monitor activity, and act on potential attacks. The system itself requires time to learn, time to manage, and time to update. which requires people and additional people aren’t really in the spending plan nowadays.

Operational efficiency means less time managing while accomplishing the security checklist items you are supposedly responsible for. There is clearly a cost to having analysts gather data from numerous security consoles and having to do analysis and correlation in their own heads. Automating much of this analysis clearly increases the efficiency of the folks you already have.

Thus you can justify this use case by talking about the number of staff you won’t have to hire via the intelligent use of automation. Lots of folks get scared by this justification tactic, since they figure talking about efficiency means they’ll be expected to cut headcount. That’s short sighted because most security teams are woefully understaffed, which means the only hope is to automate activities and improve efficiency. Using hard time and cost metrics for these tasks, you can directly generate a number for activities that you won’t have to do, thus saving money.

React Faster

Finally, the react faster use case focuses on improving security by accelerating detection of attacks. So how do we quantify the benefits of this kind of use case? Let’s look at the economic impact of improved security:

  • Reduce downtime (increase availability) – Here we’d need to model the cost of downtime by some measure. Perhaps it’s lost orders. Or unhappy customers. Or failure to ship merchandise. There are lots of ways to quantify downtime, odds are your operations folks have a method they’ve used to get management tools.
  • Brand impact of breach – You can also work to estimate the negative effect on the organization’s brand of a high profile breach. Right, that’s about as scientific as throwing a dart.
  • Cost of disclosure and clean-up - Less squishy is the cost of notifying customers of a problem and cleaning up the mess caused by a successful attack. There are standard numbers of the cost to clean up based upon customer records compromised, so that’s pretty easy to quantify.

Clearly this is the hardest situation to build a compelling cost justification. Securosis has done a lot of research into this kind of squishy business justification (and tried to make it a bit less squishy). We recommend you take a look at our Business Justification for Data Security white paper to get a feel for how to structure a process to quantify risks and losses when hard numbers are not available. Sure, we think ROI is the flying Unicorn of statistics, but we do provide qualitative and quantitative approaches to produce estimates of tangible cost reduction.

To be clear, many organizations don’t even bother trying to come up with a dollar figure for improved security, rather using this as qualitative additional value for an investment – as opposed to the main economic driver.

Packaging Your Business Case

The level of justification and packaging you need to get the project approved will be dependent on your specific environment. Some organizations need terribly formal documents, with spreadsheet models and ROI calculations. Others will take a quick slide deck with the highlights and the inklings of the depth of analysis. Obviously do the least you need to get the green light for the project. The more time you spend concocting ROI models, the less time you have for fighting the bad guys.

—Mike Rothman

Monday, May 17, 2010

Is Twitter Making Us Dumb? Bloggers, Please Come Back

By Rich

When I first started the Securosis blog back in 2006 I didn’t really know what to expect. I already had access to a publishing platform (Gartner), and figured blogging would let me talk about the sorts of things that didn’t really fit my day job.

What I didn’t expect, what totally stunned me, was the incredible value of participating in a robust community holding intense debates, in the open, on the permanent record. Debates of the written word, which to be cogent in any meaningful way take at least a little time to cobble together and spell check. I realized that the true value of blogging isn’t that anyone could publish anything, but the inter-blog community that develops as we cross-link and cross comment.

It’s how Mike Rothman and I went from merely nodding acquaintances at various social functions, to full business partners. I met Chris Hoff when I blogged I was rolling through his home town, and he then took me out to dinner. Since then we’ve paired up for 2 years of top rated sessions at the RSA Conference, and become good friends. Martin McKeay went from some dude I’d never heard of to another close friend, with whom I now podcast on a weekly basis. And those three are just the tip of the list.

Blogging also opened my world in ways I could never have anticipated. This open dialog fundamentally changed opinions and positions by exposing me to a wider community. Gartner was great, but very insular. I talked with other Gartner analysts, Gartner customers, and vendors… all a self-selecting community. With blogging, I found myself talking with everyone from CEOs to high school students.

At least I used to, because I feel like that community, that experience, is gone.

The community of interlinked blogs that made such an impact on me seems to be missing. Sure, we have the Security Blogger’s Network and the Meetup at RSA, but as I go through my daily reading and writing, it’s clear that we aren’t interacting at nearly the level of even 2 years ago. Fewer big debates, fewer comments (generally), and fewer discussions on the open record.

I’m not the only one feeling the loss. Every Tuesday and Thursday we try to compile the best of the security web for the Securosis Incite and Friday Summary, and the pickings have been slim for a while now. There are only so many times we can link back to Gunnar, Bejtlich, or the New School. Heck, when we post the FireStarter on Monday, our goal isn’t to get comments on our site (although we like that), but to spur debate and discussion on everyone else’s sites.

As you can tell by the title, I think Twitter is a major factor. Our multi-post debates are now compressed into 140 characters. Not that I dislike Twitter – I love it (maybe too much), but while it can replace a post that merely links to a URL, it can’t replace the longer dialog or discussions of blogging. I’m too lazy to run the numbers, but I’ve noticed a definite reduction in comments on our blog and blogging in general as Twitter rises in popularity. I’ve had people flat-out tell me they’ve given up on blogging to focus on Twitter. Correlation isn’t causation, and the plural of anecdote isn’t data, but anyone who was on the scene a few years ago easily sees the change.

When I brought this up in our internal chat room, Chris Pepper said:

It’s a good point that if you have a complicated thought, it’s probably better to stew on it and build a post than to type whatever you can fit in 140 characters, hit Return, then sigh with relief that you don’t have to think about it any more.

Dear Bloggers,

Please come back. I miss you.

-me

—Rich

DB Quant: Planning Metrics (Part 3): Planning for Monitoring

By Adrian Lane

Continuing to define metrics in the planning phase of our database security program, we move on to Planning for Monitoring.

Today we’ll focus on defining the metrics and plannning how to set up a monitoring program, which we initially identified as:

  1. Define Activities
  2. Define Violations
  3. Identify Event Collection Method
  4. Define Event Response
  5. Document

Although the process is straightforward, there is sometimes a bit of confusion due to how we define monitoring. Monitoring is different than auditing, which uses native audit logging features of the database – typically for forensics, compliance, and performance management. Monitoring, on the other hand, is a near-real-time activity where we watch all database activity and record or alert on actions based on policies. Aside from being real-time and its policy features, monitoring is more likely to be cross-platform and often collects a wider range of activity than auditing (especially SELECT queries).

Some of the redundancy in this phase is due to having to define policies at the business level with those stakeholders, to implement them technically, and to build processes around everything. Since many of these policies apply across multiple databases/business units, it makes sense to place them in the planning section as opposed to the Monitoring (implementation) phase we will cover later.

Let’s dig into the steps and metrics.

Define Activities

Variable Notes
Time to identify covered business processes
Time to gather security and compliance requirements

Define Violations

Variable Notes
Time to define suspect behavior e.g., what should not happen
Time to define abnormal use cases Map which behaviors indicate security failure or compliance event
Time to update existing standards and policies
Time to determine appropriate response and criticality

Identify Event Collection

Variable Notes
Time to identify major applications (Optional) The major data sources to be used; often ERP, financial systems, and payment processing
Time to map events to standards and policies e.g., map which events to collect, analyze, and report
Time to establish priority (Optional) Define order of event processing or filtering if needed
Time to determine ownership Who owns the policy
Time to specify notification How suspect events and information are recorded and distributed

Define Event Responses

Variable Notes
Time to define event response per rule Who gets notified
Time to determine ownership Who responds to the event
Time to specify criticality per rule How important the event is, in terms of IT priorities
Time to define verification method/workflow Must provide clear evidence of completion

Document

Variable Notes
Time to document standard Both policies and rules
Time to distribute standard and educate team members

This looks huge and complex, which it might be in a large organization (remember that in Quant we are showing a complete set of processes, not all of which you will use). Essentially, this phase identifies key activities to monitor on the business side, converts them into technical rules, and establishes an incident handling process.


Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2

—Adrian Lane

Talking Database Assessment with Imperva

By Adrian Lane

I will be presenting a webinar: “Understanding and Selecting a Database Assessment Solution” with Imperva this Wednesday, May 19th at 11am PST / 2pm EST. I’ll cover the deployment models, key features, and ways to differentiate assessment platforms. I’ll spend a little more time on applicability for compliance, as that is the key driver for adoption now, but cover other use cases as well.

You can register and sign up for the webinar. As always, if you have questions you would like addressed, you can email me prior to the presentation.

—Adrian Lane

FireStarter: Killing the Next Generation

By Mike Rothman

As a former marketing guy, I’m sensitive to meaningless descriptors that obfuscate the value a product brings to a customer. Seeing Larry Walsh’s piece on next generation firewalls versus UTM got my blood boiling because it’s such a meaningless argument. It’s time we slay the entire concept of ‘next generation’ anything.

Hard to find the right place for this... That’s right, I’m saying it. The concept of a next generation is a load of crap. The vendor community has taken to calling incremental iterations ‘next generation’ because they can’t think of a real reason customers should upgrade their gear. Maybe the new box is faster, so the 2% of the users out there actually maxing out their gear get some relief. Maybe it’s a little more functional or adds a bit more device support. Again, this hardly ever provides enough value to warrant an upgrade. But time and time again, we hear about next generation this or next generation that. It makes me want to hurl.

I guess we can thank the folks at Microsoft, who perfected the art of forced upgrades with little to no value-add. Even today continue to load into office suites feature after feature that we don’t need. If you don’t believe me, open up that old version of Word 2003 and it’ll work just fine.

Let’s consider the idea of the “next generation firewall,” which I highlighted in last week’s Incite with announcements from McAfee and SonicWall. Basically SonicWall’s is bigger and McAfee’s does more with applications. I would posit neither of these capabilities are unique in the industry, nor are they disruptive in any way. Which is the point. To me, ‘next generation’ means disruption of the status quo. You could make the case that Salesforce.com disrupted the existing CRM market with an online context for the application. A little closer to home, you could say the application white listing guys are poised to disrupt the endpoint security agent. That’s if they overcome the perception that the technology screws up the user experience. For these kinds of examples, I’m OK with ‘next generation’ for true disruption.

But here’s the real problem, at least in the security space: End users are numb. They hear ‘next generation’ puffery from vendors and they shut down. Remember, end users don’t care whether the technology is first, second, third, or tenth generation. They care whether a vendor can solve the problem.

What example(s) do we have of a ‘next generation’ product/category really being ‘next generation’? Right, not too many. We can peek into the library and crack open the Innovator’s Dilemma again. The next generation usually emerges from below (kind of like UTM) targeting a smaller market segment with similar capabilities delivered at a much better price point. Eventually the products get functional enough to displace enterprise products, and that is your next generation.

Riddle me this, Batman, what am I missing here? And all you marketing folks lurking (I know you’re out there), tell me why you continue to stand on the crutch of ‘next generation’, as opposed to figuring out what is important to end users. I’d really like to know.

Photo credit: “BPL’s Project Next Generation” originally uploaded by The Shifted Librarian

—Mike Rothman

Friday, May 14, 2010

Friday Summary: May 14, 2010

By Adrian Lane

I was rummaging through the closet yesterday, when I came across some old notebooks from college. Yes, I am a pack rat. One of the books contained notes from Computer Science 110: Algorithm Design. Most of the coursework was looking for ways to make algorithms more efficient, and to select the right algorithm to get the job done. I remember spending weeks on sorting routines: bubble sort, merge sort, heap sort, sorts based upon the Fibonacci sequence, Quicksort, and a few others. All of which we ran against sample data sets; comparing performance; and collecting information on best case, median, and worst case results. Obviously with a pre-sorted list they all ran fast, but depending on the size and distribution of the data set our results were radically different.

The more interesting discussion was the worst-case scenarios. One of the topics for discovering them was the Adversary Technique. Basically the adversary would re-arrange the data to make it as difficult as possible to sort. The premise was that, knowing the algorithm compared elements, (e.g., is X >= Y) the adversary would re-arrange all data elements into an order that forced the highest number of comparisons to be made. Some of the sorts were brilliant on average, but would be computing results until the end of time when confronted by a knowledgable adversary.

All the sort algorithms are long since purged from my memory, and I can truthfully say I have never needed to develop a sorting routine in my entire career. But the adversary technique has been very useful tool in designing code. I really started using a variant of that method for writing error-handling routines so they worked efficiently while still handling errors. What is the most difficult result I could send back? When you start trying to think of errors to send back to a calling application, it’s amazing what chaos you can cause. The first time I saw an injection attack, a malicious stream sent back from a .plan file, I thought of the intelligent adversary. This is also a pretty handy concept when writing communication protocols, where you have to establish a trust relationship during multi-phase handshaking – the adversary technique is very good for discovering logic flaws. The intelligent adversary teaches you to ask the right questions, and is useful for identifying unnecessary complexity in code. If you don’t do this already, try a little adversarial role-playing the next time you have design work.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Project Quant Posts

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. Technically my favorite comment of the week was by David Mortman, professing shock that Andre Gironda actually agreed with someone, on a public forum no less! But alas, as he did not leave it on the blog, the award has to go to starbuck, in response to Secure Development Lifecycle–You’re Doing It Wrong.

“Before you know it, HR reps will be including “SDL certification” requirements on every engineering job description, without a clue what they are demanding or why, so let’s stop this train before it runs too far off the tracks.”

Damn right. By the way, I didn’t really see the point of your article at first as it seems quite logic to me that adopting the methodology/process that one of the biggest software editors adopted would require very strong adaptation. Then I remembered myself almost three years ago when I printed out the SDL process and came to the meeting room bragging about it “Yeah, that’s what we’ll do!!!” And I also remember the moment, one year after, when I realized that these models were just…models, that small ISVs like the one I was working for couldn’t afford both financially and technically.

Now, the most interesting (from my humble opinion) of your recommendations is the 5th one: Do what MS did, not what they do. That’s what happens, ironically: the SDL process describes Microsoft’s maturity model at its most mature stage but lacks guidance on how to reach it (the assessment kind of helps but…anyway). Every company has its own needs and resources and SDL does not provide any insights on how to identify the appropriate roadmap (aka: the cheapest and most risk-mitigating approach).

That’s a selling point of the OpenSAMM process, which proposes industry-oriented maturity roadmaps that should help the organization walk along the path towards a mature software development lifecycle. I am currently deploying security within an existing SDLC with a massive amount of developers, based on the OpenSAMM guidance. Within six months I hope I will be able to have some thoughts to share on the differences between working with SDL and working with OpenSAMM.

Let’s hope they will be more positive than my experience with SDL.

Thanks for your article!!

—Adrian Lane

Thursday, May 13, 2010

Unintended Consequences of Consumerization

By Mike Rothman

The ripple effect, of how a small change creates a major exposure down the line, continues to amaze me. That’s why I enjoyed the NetworkWorld post on how the iPad brings a nasty surprise. The story is basically how the ability for iPads to connect to the corporate network exposed a pretty serious hole in one organization’s network defenses.

Basically a minor change to the authentication mechanism for WiFi smart phones allowed unauthorized devices to connect to the corporate network. It’s an interesting read, but we really need to consider the issues with the story. First, clearly this guy was not scanning (at all) for rogue devices or even new devices on the network. That’s a no-no. In my React Faster philosophy, one of the key facets is to know your network (and your servers and apps too), which enables you to know when something is amiss. Like having iPads (unauthorized devices) connecting to your corporate network.

So how do you avoid this kind of issue? Yes, I suspect you already know the answer. Monitoring Everything gets to the heart of what needs to happen. I’ll also add the corollary that you should be hacking yourself to expose potential issues like this. Your run-of-the-mill pen test would expose this issue pretty quickly, because the first step involves enumerating the network and trying to get a foothold inside. But only if an organization systematically tries to compromise their own defenses.

Most importantly, this represented a surprise for the security manager. We all know surprise = bad for a security person. There are clear lessons here. The iPad won’t be the last consumer-oriented device attempting to connect to your network. So your organization needs a policy to deal with these new kinds of devices, as well as defenses to ensure random devices can’t connect to the corporate network – unless the risk of such behavior is understood and accepted. Every device connecting to the network brings risk. It’s about understanding that risk and allowing the business folks to determine whether the risk is worth taking.

—Mike Rothman

SAP Buys Sybase

By Adrian Lane

I am sitting on the porch reading a Sybase ASE document on transparent database encryption, so it’s ironic that a few minutes ago I got word that [SAP bought Sybase for $5.8 billion](http://www.businessweek.com/news/2010-05-12/sap-buys-sybase-for-5-8-billion-to-step-up-rivalry-with-oracle.html in cash). SAP posted a press release. This announcement is right on the heels of their partnership announcement last March.

It’s been my feeling for several years now that relational databases have been on a steady retreat back into the core of the enterprise, from whence they came. Smaller, modular, more agile repositories are in vogue for everything outside enterprise IT data centers. They are easier and more accessible to developers, and they are free. I bring this up because this is one of the ways Sybase has been squeezed out of the enterprise relational database market. Let’s be honest – people looking for a new database now either go cheap and select a PostgreSQL / MySQL platform, or pay for the name brand / stack synergy / bundled pricing discounts for Oracle or IBM. Sybase has been steadily growing over the last five years due to new product offerings, but they remain something of an afterthought in the enterprise database market. Sybase does not enter into the discussion of new database sales, so they rely on keeping their current installed base happy and growth of their mobile offerings.

And it’s not easy to succeed with Oracle undercutting them on price and IBM going after all their hardware vendor relationships. SAP levels the playing field for Sybase, putting them in a position to grow and get visibility with a larger body of prospects. Sybase gives SAP a technologically current database platform, an analytics engine, mobile data/device support and some other tools. Honestly, many of us had been wondering how long it would be before someone like SAP bought them. Sybase could not compete head to head in the relational database space without this relationship – not because of the technology, but due to customer preference to reduce risk by buying from stable providers. I really hate saying it, but the purchase legitimizes Sybase products and viability. An established company with over a billion in revenue should not need such endorsements, but when competing with Oracle and IBM, they do.

—Adrian Lane

Wednesday, May 12, 2010

We Have Ways of Making You ... Use a Password

By Adrian Lane

MSNBC has an interesting news item: a German court is ordering all wireless routers to have a password, or the owners will be fined if it is discovered that someone used their connection illegally. From the post:

Internet users can be fined up to euro 100 ($126) if a third party takes advantage of their unprotected WLAN connection to illegally download music or other files, the Karlsruhe-based court said in its verdict. “Private users are obligated to check whether their wireless connection is adequately secured to the danger of unauthorized third parties abusing it to commit copyright violation,” the court said.

OK, so this is yet another lame attempt to stop people from sharing music and movies by trying to make the ‘ISP’ (a router owner in this case) an accessory to the crime. I get that, but a $126.00 fine, in the event someone is caught using your WiFi illegally and they prosecuted, is not a deterrent. But there are interesting possibilities to consider.

  1. Would the fine still apply if the password was ‘1234’?
  2. What if they had a password, but used WEP? Some routers, especially older routers, use WEP as the default. It’s trivial to breach and gain access to the password, so is that any better? Do we fine the owner of the router, or do we now fine the producer of the router for implementing crappy security? Or is the manufacturer covered by their 78 page EULA?
  3. Many laws start as benign, just to get a foothold and set precedence, then turn truly punitive after time. What if the fine was raised to $1,260, or $12,600? Would that alter your opinion?

I cannot see an instance where this law makes sense as a deterrent to the actions it levies fines against.

—Adrian Lane

Incite 5/12/2010: the Power of Unplugging

By Mike Rothman

I’m crappy at vacations. It usually takes me a few days to unwind and relax, and then I blink and it’s time to go home and get back into the mess of daily life. But it’s worse than that – even when I’m away, I tend to check email and wade through my blog posts and basically not really disconnect. So the guilt is always there. As opposed to enjoying what I’m doing, I’m worried about what I’m not doing and how much is piling up while I’m away. This has to stop. It’s not fair to the Boss or the kids or even me. I drive pretty hard and I’ve always walked the fine line between passion and burnout. I’m happy to say I’m making progress, slowly but surely.

Hard to find the right place for this... Thanks to Rich and Adrian, you probably didn’t notice I’ve been out of the country for the past 12 days and did zero work. But I was and it was great. Leaving the US really forces me to unplug, mostly because I’m cheap. I don’t want to pay $1.50 a minute for cell service and I don’t want to pay the ridonkulous data roaming fees. So I don’t. I just unplug.

OK, not entirely. When we get to the hotel at night, I usually connect to the hotel network to clean out my email, quickly peruse the blog feeds and call the kids (Skype FTW). Although WiFi is usually $25-30 per day and locked to one device. So I probably only connected half the days we were away.

The impact on my experience was significant. When I was on the tour bus, or at dinner with my friends, or at an attraction – I didn’t have my head buried in the iWhatever. I was engaged. I was paying attention. And it was great.

I always prided myself on being able to multi-task, which really means I’m proficient at doing a lot of things poorly at the same time. When you don’t have the distractions or interruptions or other shiny objects, it’s amazing how much richer the experience is. No matter what you are doing.

Regardless of the advantages, I suspect unplugging will always remain a battle for me, even on vacation. Going out of the US makes unplugging easy. The real challenge will be later this summer, when we do a family vacation. I may just get a prepay phone and forward my numbers there, so I have emergency communications, but I don’t have the shiny objects flashing at me…

But now that I’m thinking about it, why don’t more of us unplug during the week? Not for days at a time, but hours. Why can’t I take a morning and turn off email, IM, and even the web, and just write. Or think. Or plan world domination. Right, the only obstacle is my own weakness. My own need to feel important by getting email and calls and responding quickly.

So that’s going to be my new thing. For a couple-hour period every week, I’m going to unplug. Am I crazy? Would that work for you? It’s an interesting question. Let’s see how it goes.

– Mike

Photo credits: “Unplug for safety” originally uploaded by mag3737


Incite 4 U

  1. Attack of the Next Generation Firewalls… – Everyone hates the term ‘next generation’, but every vendor seems to want to convince the market they’ve got the next best widget and it represents the new new thing. Example 1 is McAfee’s announcement of the next version of Firewall Enterprise, which adds application layer protection. Not sure why that’s next generation, but whatever. It makes for good marketing. Example 2 is SonicWall’s SuperMassive project, which is a great name, but seems like an impedance mismatch, given SonicWall’s limited success in the large enterprise. And it’s the large enterprise that needs 40Gbps throughput. My point isn’t to poke at marketing folks. OK, maybe a bit. But for end users, you need to parse and purge any next generation verbiage and focus on your issues. Then deploy whatever generation addresses the problems. – MR

  2. Cry Havok and Let Slip the Lawyers – I really don’t know what to think of the patent system anymore. On one hand are the trolls who buy IP, wait for someone else to actually make a product, and then sue their behinds. On the other is the fact that patents do serve a valuable role in society to provide economic incentive for innovation, but only when managed well. I’m on the road and thus haven’t had a chance to dig into F5’s lawsuit against Imperva for patent infringement on the WAF. Thus I don’t know if this is the real deal or a play to bleed funds or sow doubt with prospects, but I do know who will win in the end… the lawyers. – RM

  3. Bait and Switch – According to The Register, researchers have successfully exercised an attack to bypass all AV protection. “It works by sending them a sample of benign code that passes their security checks and then, before it’s executed, swaps it out with a malicious payload.” and “If a product uses SSDT hooks or other kind of kernel mode hooks on similar level to implement security features it is vulnerable.” I do not know what the real chances for success are, but the methodology is legit. SSDT has been used for a while now as an exploit path, but this is the first time that I have heard of someone tricking what are essentially non-threadsafe checker utilities. A simple code change to the scheduler priorities will fix the immediate issue, but undoubtedly with side effects to application responsiveness. What most interests me about this is that it illustrates a classic problem we don’t see all that often: timing attacks. Typically this type of hack requires intimate knowledge of how the targeted code works, so it is less common. I am betting we’ll see this trick applied to other applications in the near future. – AL

  4. Just Do Something… – I get a lot of questions about how to get started in information security, like most of you. For some reason, if you are reasonably high profile in the business, folks think we know some kind of shortcut to get established. We’ve already talked about the benefits of social networking, but ultimately this post from Adam nails it. Just do something. Volunteer at your church. Help out the kid’s nursery school or your favorite charity. They have computers and Internet connectivity, so they’ve got security problems. If you are willing to trade time for experience, then you can learn and get established in this space. But certainly not if you view getting a security job as a chicken/egg problem. – MR

  5. It’s not what you know, it’s what you think you know – Hilarious post by James Iry titled “A Brief, and Mostly Wrong History of Programming Languages. I especially love the comments on COBOL. But I think the post is missing a couple important landmarks:

    1. September 1973, Lotfi Zadeh creates a paper on Fuzzy Logic. An inadvertent side effect is discovery of Zadeh’s theorem, proving it is possible to simultaneously be a supergenius and the village idiot.
    2. April 1994, Kernighan and Ritchie finally admit that Unix and C are a hoax: “We stopped when we got a clean compile on the following syntax: for(;P(“n”),R-;P(“|”))for(e=C;e-;P(“_”+(*u++/8)%2))P(“| “+(*u/4)%2);”.
    3. November 1995, James Gosling quietly released “Oak white paper” and no one notices. After scolding by marketing executives “What kind of a stupid $^@&#% name is ‘Oak’?”, the white paper was re-launched as “Java white paper” in December of that year to international acclaim.
    4. April 1974, honorable mention to Professor Stonebreaker, who launches the Ingres Relational Database with QUEL and SQL programming languages. Ingres hires dedicated programmer-monks to fulfill revolutionary vision. Resultant code is so dazzling and stupendous that they forget to hire sales team and go bankrupt. – AL
  6. More Who DAT Fail Impact – It’s been a few weeks since the McAfee DAT update fiasco; and as I was out of pocket for two weeks, I’m catching up on it, but I wonder if anyone took Rob Graham up on his offer to analyze the real number of failed machines. We also saw McAfee’s financial results suffer (earnings transcript) and you have to wonder whether customers looking at big McAfee renewals will look elsewhere. Finally, McAfee is going to help customers clean up, which seems either like a blank check (if done right) or a marketing ploy (if done wrong), but either way the old adage about it taking years to build credibility and only seconds to lose it is reality here. Set your clocks for three months from now: MFE’s next financial announcement should be interesting. – MR

  7. Happy Birthday LoveBug – Can it really be 10 years since the ILOVEYOU virus hit… hard? I still tell the story about getting the virus sent to me by the Chairman of RSA (Chuck Stuckey) and it keeps geting big laughs. But what have we learned over the past decade? We live in a dynamic world. Once we close one attack vector, the bad guys find the next. It’s an arms race, baby, and there is no end in sight. So remember LoveBug, get nostalgic for a minute, and then get back to work. Because blended threats won’t wait and zombies don’t sleep. We need more than a can of Raid to deal with today’s bugs. – MR

  8. Thoughts on Minimalism – Being out of the country always gives me perspective on the “reality” that is life in the US. Just driving around my neighborhood really brought it home. We’ve got space, we live in relatively big houses, we’ve got relative wealth, and we are still unhappy. At least most of us. So stumbling across this post on the ZenHabits blog about minimalism provided a good reminder that stuff doesn’t make us happy. The point here is to be happy with what you have and stop making yourself crazy trying to get that stuff you probably don’t need anyway. I talk about this a lot, and I don’t do particularly well in practicing what I preach, but at least I recognize where I’m trying to go, and maybe one day I’ll even get there. – MR

—Mike Rothman

Monday, May 10, 2010

DB Quant: Planning Metrics (Part 2)

By Adrian Lane

Today we will identify key cost metrics for planning Authentication, Access, and Authorization (AAA). Crafting access strategies is time-consuming, and it is difficult to provide data security without imposing overly burdensome setup and management tasks. Meeting compliance requirements, and implementing segregation of duties to prevent fraud, make the process even more demanding. While the process we described for the planning phase strategic, there are still plenty of moving parts to account for.

We previously defined the process as:

  1. Determine Requirements: Figure out internal functions and external compliance requirements (e.g., authentication for PCI systems).
  2. Define Policies: For users, objects and repositories.
  3. Define Implementation
    1. Define approved authentication mechanisms.
    2. Define allowed access control mechanisms.
  4. Document

After some more review, we have refined it a bit:

<

div class=”bodyTable”>

Determine Requirements

Variable Notes
Time to identify business groups and functions
Time to locate internal business requirements for Access/Authentication/Authorization
Time to identify/gather external security and compliance requirements

Define Policies for Users, Objects, and Repositories

Variable Notes
Time to specify business functions Only major business functions, e.g., accounting for General Ledger access vs. AR
Time to map business functions to logical roles
Time to determine object and data ownership Again, only for major applications. Typically this is ERP, CRM, and HR
Time to determine necessary administrative roles The different DBA accounts needed to support segregation of duties

Define Implementation Strategy

Variable Notes
Time to identify which organizations will be supported Both internal and external
Time to define approved authentication mechanisms
Time to define allowed access control mechanisms
Time to identify legitimate and unwanted access methods The different ways of connecting with the DB – e.g., ODBC over SSL with approved port numbers
Time to define database administrator roles

Document

Variable Notes
Time to document standard
Time to distribute standard and educate team members

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. Planning Metrics, Part 1

—Adrian Lane

FireStarter: Secure Development Lifecycle—You’re Doing It Wrong

By Adrian Lane

I wrote last Monday’s FireStarter on Process and Peer Pressure because there were a few things bothering me that I needed to get out of my system, but I saved a lot for later. I didn’t really intend to write this followup so soon, but I saw that Cisco announced their own Software Development Lifecycle. I wanted to make some statements on SDL later this year when I begin publishing more concrete Secure Software Development Lifecycle (SSDL in Securosis parlance, SDL for most organizations) guidelines, but Cisco’s announcement changes things. I worry that sheer inertia will prompt the industry as a whole to rubber-stamp SDLs. Before you know it, HR reps will be including “SDL certification” requirements on every engineering job description, without a clue what they are demanding or why, so let’s stop this train before it runs too far off the tracks.

If you are thinking about incorporating Secure Development Lifecycle practices for software development, that’s great. If you have read about Microsoft’s SDL, witnessed Microsoft’s success, seen Cisco’s endorsement, and believe their model will work for you, just stop. It’s not going to work for you. It’s based on a lot of factors and assumptions that do not pertain to you. It’s not a template for your requirements.

Adopting MS-SDL wholesale is a little like a child putting on adult clothes because they want to be ‘big’. You cannot drop that particular process into your development organization and have it fit. More likely you will break everything. Your team will need to change their skills and priorities, and though it sounds cliche, people are resistant to change. Existing processes need to be adjusted to accommodate secure development processes and techniques. You will need new tools, or to augment existing ones. You will need a whole new class of metrics and tracking. And everything you pick the first time will need several iterations of alteration and adjustment before you get it right – this isn’t Microsoft’s first attempt either.

It’s not that the SDL is bad – it isn’t. Microsoft did an excellent job with their SDL. It’s very well thought out, incorporates most effective defect detection techniques, has clearly evolved through several revisions, and includes intelligent tradeoffs in places where there is no single ‘right’ answer. But it is their SDL, not yours. If you take the SDL Microsoft has described and try to implement it, you will fail. I am talking to the 99% of people out there who would think about implementing SDL and think “Hey, Microsoft published this new thingie for free; let’s use it and save ourselves the time and money!” Wrong.

Here’s why:

  1. Too Big: This process is geared for very large firms, with lots of resources, and a genuine desire to get better. You may not need all of it and frankly it would be overwhelming to start with. This is huge – I mean really huge. You are not going to swallow this elephant in a single gulp.
  2. Organic Evolution: Microsoft’s success is not just the introduction of process and techniques. It was not just hiring a handful of really good people and helping to educate the development staff. The MS-SDL reflects several years of focused evolution, and in software that is a lot. They spent a long time looking at the code and figuring out what was wrong. They developed their own tools to help discover problems. They developed software to help track their progress and provide metrics to demonstrate what worked and what did not. They evolved their own threat modeling. They tried, revised, fixed and re-implemented most of what they do several times over. Don’t think their publishing a guide can save you this pain – it cannot.
  3. Resources: People, Tools, and Time are the three classic resources you have when you build code. Resources are scare. Always. OK, if you have billions of dollars in the bank, or you are a bank, you might not be quite as pinched for resources. But developing quality code is expensive. Microsoft had the money to hire some of the best people, to buy or build the best tools, a willingness to take additional time for security before releasing software, and then hire some more of the best people. Your developers work nights and weekends to get the release out the door and collapse in a heap, dreaming about all the things they wanted to do before the code was released. Cisco? Yeah, they can do this. You? You don’t have the resources to do everything, so you need to pick and choose.
  4. Appropriateness of Techniques: Your program calls for white box testing. Great, but you don’t own critical code you rely on. You leverage open source where you can get code, but off-the-shelf software and even Microsoft tools do not provide source code. If you have four thousand web pages, and most of them don’t filter input values, do you really think you are going to fix this in the current release cycle, or are you going to deploy a WAF? If you are starting an application from scratch, your first step will be threat modeling. If you have a huge existing application, forget threat modeling for now – pen testing is probably much more effective and efficient. And it’s not just which techniques, but how you use them. Within all these techniques, there are many variations and supporting requirements that need tweaking so they can work for you. We discuss these tradeoffs in the Use Case portion of Understanding and Selecting a Web Application Security Program white paper, but the point is that the right choice for you is different than the right choice for Microsoft or Cisco, and you can’t discover what’s right for your environment by reading their SDLs.
  5. Do what Microsoft did, not what they do: Using the SDL as your program is a really bad thing to do. I really hope people don’t take this as a slam against Microsoft – my point is to follow Microsoft’s example, rather than their SDL. You need to do what Microsoft did, because you cannot simply jump ahead to what Microsoft is doing today. Microsoft’s journey to where they are now is far more interesting and useful than the specific tools and techniques they eventually settled on. You can learn by example, sure, but you need to answer the same questions – sometimes with different answers, as dictated by your own constraints – to evolve your own process from the beginning. That comes from hard work and analysis, with lots of trial and error mixed in.

There is no shortcut, no secret sauce, no package of Instant Code-Be-Secure. One size does not fit all. Admire what Microsoft has done, for their customers and for the community, learn, and then figure what is relevant to you. You don’t have to completely start from scratch, but you have got work to do in figuring out how you are going to build your own Secure Development Lifecycle.

—Adrian Lane

Friday, May 07, 2010

Friday Summary: May 7, 2010

By Rich

Yesterday I finished up a presentation for the Secure360 Conference: “Putting the Fun in Dysfunctional – How the Security Industry Works, and Why It’s Your Fault”. This is a combination of a bunch of things I’ve been thinking about for a while, mostly focused on cognitive science and economics. Essentially, security makes a heck of a lot more sense once you start trying to understand why people make the decisions they do, which is a combination of their own internal workings and external forces. Since it’s very hard to change how people think (in terms of process, not opinion), the best way to induce change is to modify the forces that drive their decision making.

I have a section in the presentation on cognitive bias, which is our tendency to make errors in judgement due to how our brains work. It’s pretty fascinating stuff, and essential knowledge for anyone who wants to improve their critical thinking. Here are some examples relevant to the practice of security (from Wikipedia):

  • Framing by using a too-narrow approach and description of the situation or issue.
  • Hindsight bias, sometimes called the “I-knew-it-all-along” effect, is the inclination to see past events as being predictable.
  • Confirmation bias is the tendency to search for or interpret information in a way that confirms one’s preconceptions – this is related to cognitive dissonance.
  • Self-serving bias is the tendency to claim more responsibility for successes than failures. It may also manifest itself as a tendency for people to evaluate ambiguous information in a way beneficial to their interests.
  • Bandwagon effect: the tendency to do (or believe) things because many other people do (or believe) the same. Related to groupthink, herd behavior, and mania.
  • Base rate fallacy: ignoring available statistical data in favor of particulars.
  • Focusing effect: prediction bias which occurs when people place too much importance on one aspect of an event – this causes errors when attempting to predict the utility of a future outcome.
  • Loss aversion: “the disutility of giving up an object is greater than the utility associated with acquiring it”.
  • Outcome bias: the tendency to judge a decision based its eventual outcome, rather than by the information available when it was made.
  • Post-purchase rationalization: the tendency to persuade oneself that a purchase was a good value.
  • Status quo bias: our preference for to stay the same (see also loss aversion and endowment effect).
  • Zero-risk bias: preference for reducing a small risk to zero, over a greater reduction in a larger risk.

Cognitive bias also has interesting ties to logical fallacies, another essential area for any good security pro or skeptic.

Not that understanding psychology and economics solves all our problems, but they sure help reduce the frustration. And applied to ourselves, understanding can really improve our ability to analyze information and make decisions. Cool stuff.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

  • Rich: 2010 DBIR to include cases from U.S. Secret Service This is simply awesome! The Secret Service is analyzing all their cases from the past couple years using Verizon’s framework. This is a gold mine for those of us who care about real world security (disclosure – I’m on the board of the VERIS project for Verizon, but I am not compensated in any way).
  • Adrian Lane: What Egress Filters Should I Use? Branden Williams offers a pragmatic discussion of egress filtering.

Project Quant Posts

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Betsy Nichols, in response to Thoughts on Data Breach History.

Very interesting presentation. The OSF is doing amazing work in two areas: data breaches and vulnerabilities. It is amazing what they have accomplished with a volunteer community. They are definitely a worthwhile cause that merits broad support from all of us who benefit from their work.

You and other interested folks in the Securosis community may be interested in some of the quantitative analysis I have done using the OSF DataLossDB. You can see it at www.metricscenter.net. (No login necessary.) Just go to the Dashboards area of the site. I have posted two that are based on the DataLossDB.

The first dashboard is titled Public Data Breaches which is solely based on the DataLossDB and presents some basic stats.

The second dashboard is titled Stock Price Impact. This looks at mashing up data from the DataLossDB with Google Finance data to get insight on the question “What is the impact of a breach on a public company’s stock price”.

—Rich

Thursday, May 06, 2010

DB Quant: Planning Metrics (Part 1)

By Rich

We are finally starting to roll into the final phase of our Project Quant for Databases project. So far we have defined a database security process framework, and rolled through each of the phases to detail the steps. We have mentioned dozens of ways you can invest time and money, and we need to create specific measurements for each. As a reminder, we are keeping this more abstract than Project Quant for Patch Management, because more processes are included, and we learned that key metrics are more important to most of you than the list of hundreds of metrics we’d otherwise end up with.

This final step is actually the real meat of the project: we start defining the metrics that align with the process cycles. Today we’ll open with the first series of metrics for the Plan phase. As a reminder, this phase includes:

  • Configuration Standards
  • Authentication, Access, and Authorization Standards (AAA)
  • Monitoring Policies
  • Classification Policies

Today, we’ll focus only on the Configuration Standards steps, which we initially identified as:

  1. Identify Standards
  2. Specify Internal Standard
  3. Choose Strategy
  4. Document

Those still seem to work, so let’s dig into the steps and metrics.

Identify Standards


Determine Requirements

Variable Notes
Time to identify and collect configuration sources e.g., CIS benchmarks, NIST guidelines, vendor configuration guides
Time to locate any existing internal standards
Time to identify/gather internal security requirements
Time to identify/gather compliance requirements
Time to research practices to meet requirements

Specify Internal Standard

Variable Notes
Time to determine standards requirements

Choose Implementation

Variable Notes
Time to determine settings, controls, and configurations to meet standard
Time to determine controls priorities
Time to determine responsible party
Time to determine verification method

Document

Variable Notes
Time to document standard
Time to distribute standard and educate team members

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management

—Rich

Help Build the Mother of All Data Security Surveys

By Rich

I spend a heck of a lot of time researching, writing, and speaking about data security. One area that’s been very disappointing is the quality of many of the surveys. Most either try to quantify losses (without using a verifiable loss model), measure general attitudes to inspire some BS hype press release, or assess some other fuzzy aspect you can spin any way you want.

This bugs me, and it’s been on my to-do list to run a better survey myself. When a vendor (Imperva) proposed the same thing back at RSA (meaning we’d have funding) and agreed to our Totally Transparent Research process, it was time to promote it to the top of the stack.

So we are kicking off our first big data security study. Following in the footsteps of the one we did for patch management, this survey will focus on hard metrics – our goal is to avoid general attitude and unquantifiable loss guesses, and focus on figuring out what people are really doing about data security.

As with all our surveys, we are soliciting ideas and feedback before we run it, and will release all the raw results.

Here are my initial ideas on how we might structure the questions:

  • We will group the questions to match the phases in the Pragmatic Data Security Cycle, since we need some structure to start with.
  • For each phase, we will list out the major technologies and processes, then ask which one organizations have adopted.
  • For technologies, we will ask which they’ve researched, budgeted for, purchased, deployed in a limited manner (such as testing), deployed in initial production, and deployed in full production (organization wide).
  • For processes, we will ask about maturity from ad-hoc through fully formalized and documented, similar to what we did for patch management.
  • For the tools and processes, we’ll ask if they were implemented due to a specific compliance deficiency during an assessment.

I’m also wondering if we ask should how many breaches or breach disclosures were directly prevented by the tool (estimates). I’m on the fence about this, because we would need to tightly constrain the question to avoid the results being abused in some way.

Those are my rough ideas – what do you think? Anything else you want to see? Is this even in the right direction? And remember – raw (anonymized) results will be released, so it’s kind of like your chance to run a survey and have someone else bear the costs and do all the work…

FYI The sponsor gets an exclusive on the raw results for 45 days or so, but they will be released free after that. We have to pay for these things somehow.

—Rich