Login  |  Register  |  Contact
Thursday, May 20, 2010

Privacy Is (Still) Personal

By Rich

I want to respond to something Adam wrote about Facebook over at Emergent Chaos, but first I’m going to excerpt my own article from TidBITS:

Privacy is Personal – In the Information Age, determining what you want others to know about you isn’t always a simple decision. Aside from the potential tradeoffs of avoiding particular features or services, we all have different thresholds for what we are comfortable sharing. It’s also extremely difficult to control our information even when we do make informed decisions, and often impossible to eradicate information that escaped our control before we realized the rules of the game had changed.

For example, I use both Amazon and Netflix, even though those services also collect personal information like my buying and viewing habits. I am trading my data (and money) for a combination of convenience and personalization. I’m less concerned with these services than Facebook since their privacy practices and policies are clearer, my information is compartmentalized within each service, and they have much more consistent and stable records.

On the other hand I have minimized my usage of Google services due to privacy concerns. Google’s reach is incredibly expansive, and despite their addition of Google Dashboard to help show some of what they record, and much clearer policies than Facebook, I’m generally uncomfortable with any single company or government having that much potential information on me. I fully understand this is a somewhat emotional response.

Facebook is building a similar Internet-wide ecosystem as they expand connections to external Web sites and services. In exchange for allowing them access to your information and activities, Facebook enables new kinds of services and personalization. The question each of us must answer is if those new services and personalization options are worth the privacy tradeoff.

Deciding where to draw your own privacy lines is a very personal, complex, and even sometimes arbitrary decision. I trust Amazon and Netflix to a certain extent based on their privacy policies, even though they sometimes make mistakes (I didn’t use Amazon for years after a policy change that they later reversed). Yet I’ve limited my usage of both Google and Facebook due to general concerns (Google) or outright distrust (Facebook).

Facebook, to me, is a tool to keep me connected to friends and family I don’t interact with on a daily basis. I restrict what information it has on me, and always assume anything I do on Facebook could be public. I’m willing to trade a little privacy for the convenience of being able to stay connected with an expanded social circle. I manage Facebook privacy by not using it for anything that’s actually private.

Adam has a lot in his article, and I think his criticisms of my original post come down to:

  1. Your perceptions of your own privacy change within different contexts and over time, so what you are okay with today may not be acceptable tomorrow.
  2. If you only use the service to post things you’d want public anyway, why use it at all?

I completely agree with Adam’s first point – what you share when you are 19 years old at college is very different than what you might want people to know about you once you are 35. Even things you might share at 35 as a member of the workforce might come back to haunt you when you are 55 and running for political office.

But I disagree that this means your only option is to completely opt out of all centralized social media services. I believe we as society are reaching the point where some degree of social networking is the norm. Even “private” communications like email, IM, and SMS are open to potential disclosure and subsequent inclusion in public search results. The same used to be true of the written and spoken word, but clearly the scale and scope are dramatically larger in the Information Age. We are losing the insular layers that created our current social norms of privacy – which already vary around the world.

The last time society needed to adapt to such changes in privacy was with the Industrial Age and movement from rural to urban society. Before that, it was probably the change from hunter/gatherers to an agrarian society.

I see three possible scenarios that could develop:

  1. Society adopts a combination of laws and social mores to better protect privacy. It will be expected that you own your own data, and in the future retain a right to edit your past. Essentially, we work to protect our current expectations of privacy – which will require active effort, as the terrain has already shifted under us, and will continue to do so.
  2. Social expectations change. You’ll be able to run for political office and no one will care that you called some chick or dude hot and joined the “I love some stupid emo vampire” movement. We gain better abilities to protect our privacy, but at the same time society becomes more accepting of greater personal information being public – partially through sheer boredom at the inanity and popularity of our embarrassing peccadilloes.
  3. There is no privacy.

We have many years before these issues resolve, if ever, and it’s going to be a rough road no matter where we are headed. The end result probably won’t match any of my scenarios, but will instead be some mish-mash of those options and others I haven’t thought of. My rough guess is that society will slowly become more accepting of youthful indiscretions (or we won’t have anyone to hire or elect), but we will also gain more control over our personal information.

Privacy isn’t dead, but it is definitely changing. We all need to make personal decisions about the level of risk we are willing to accept in the midst of changing social norms, government/business influence, and degrees of control.

—Rich

Australian Border Security Insanity

By Rich

Australia is my second-favorite place on the planet to visit (New Zealand is first). But it’s a darn good thing I’m not a porn fiend, since they now require you to declare porn at the border, and, well, here’s a quote:

Australian customs officers have been given new powers to search incoming travellers’ laptops and mobile phones for pornography, a spokeswoman for the Australian sex industry says. … Fiona Patten, president of the Australian Sex Party, is demanding an inquiry into why a new question appears on Incoming Passenger Cards asking people if they are carrying “pornography”.

They are also working on a big Internet filter. You know, kind of like China and many Middle East countries. Gotta love democracy.

(Thanks to Slashdot for the pointer).

—Rich

Oracle Buys Secerno

By Adrian Lane

This morning Oracle announced that it has entered into an agreement to acquire Secerno, the UK-based Database Activity Monitoring firm. Oracle posted a FAQ on the acquisition with some generic data points. Terms of the deal have not been disclosed and, knowing Oracle, won’t be.

Many of us in the security industry are chuckling at this purchase as Oracle – at least to customers – has been disparaging Database Activity Monitoring technologies as a whole and pushing Audit Vault as an equivalent solution. But when your database is Unbreakable™, maybe you don’t need a database firewall, eh? Seriously, DAM has been a hole in their security offerings for years, and after much blustering to the contrary, they have finally plugged the hole. And from the synergies of the platforms, I’d say they did a pretty good job of it.

Key Points about the Acquisition

Here are the most important top-level points:

  1. The deal is clearly about the security alerting and blocking features of Secerno. Oracle calls it a “Database Firewall”, and never says Database Activity Monitoring. Oracle sees Audit Vault as their DAM equivalent, and has heavily disparaged that market and the techniques used by DAM vendors.
  2. Customers really struggle with Oracle patching, which makes it very difficult to keep systems compliant and secure. Positioning Secerno as a stopgap to protect the database from particular exploits so you have time to patch is reasonable and appropriate.
  3. It’s also a good straight up security play. Secerno was always stronger on security than activity monitoring for compliance, which makes it more complementary to the existing Oracle product line and security messaging.
  4. Oracle may include this in Oracle Advanced Security, or keep it standalone. We’ll have to see, but based on the current physical architecture I’d bet on stand-alone for at least a few years.
  5. In terms of messaging, expect Audit Vault to remain the focus for building those audit trails, with Secerno positioned for real-time alerting and blocking.
  6. Expect to see Oracle market “Database Firewall” with “Zero False Positives”, but those claims overlook the real world difficulties in building and maintaining query rules.

Let’s delve deeper into the specifics.

What the Acquisition Does for Oracle

  1. Fills big technology gaps: Secerno provides Oracle a lot of security technology they did not have. Secerno includes real-time analysis not available from current Oracle products, which is a growing requirement – especially for customer-facing web applications. It also gives Oracle a security tool that offers genuine heterogenous database support for Oracle, Microsoft, and Sybase (IBM support is in beta). Oracle hates to admit it, but nearly all of their enterprise clients have several different databases in use, and customers want a common platform for security or compliance when possible. Secerno provides blocking capabilities – importantly before queries reach the database – to reduce DB load and risk. Secerno has a much better UI than Oracle Audit Vault, and hopefully Oracle will continue to use it rather than standardize on their own weaker UI.
  2. Prevention: Privately we have been calling Secerno a Query White Listing technology, as we think that better encompasses what they provide. “Database Firewall” is one of those throw-away marketing terms used by several DAM vendors, but fails to differentiate what Secerno provides. Yes, Secerno will block queries, and will do so before they get to the database, reducing processing and filtering load on the database engine. I’ll get into technology details later in this post, but Oracle now has a viable way to block many unwanted queries.
  3. Web Applications: Like it or not, web applications are a huge part of the Oracle database business, and auditing is totally inappropriate for securing web applications from things like SQL injection. This helps address Oracle’s repeated issues with patching and playing catch-up with vulnerabilities, finally helping prevent some attacks without totally disrupting business operations for database updates that applications don’t support.
  4. Circumvents a perception problem: Oracle Audit still has a serious perception problem, and correctly or not is considered a performance and operations burden. On paper, Oracle’s native audit trail can provide many of the same functions as other DAM and Auditing tools, but in practice Oracle Audi pales in the light of the competition – or even Audit Vault. This helps escape serious a perception problem for compliance and security adoption.

What This Means to the DAM Market

  1. Validation: Let’s face it – when Oracle and IBM both make investments into Database Activity Monitoring, we are past wondering when DAM will be considered viable technology. Even though Oracle isn’t positioning this as DAM, Secerno did, and this serves as high-profile validation of the market.
  2. Business to be won: There were many unhappy IPLocks customers who Fortinet was unable to bring into the fold with their upgraded offerings. Some of Guardium’s business has been at risk for a while, and some of their resellers started looking for other relationships after the IBM purchase. Oracle’s customers have looked at – and in many cases purchased – other security products to close the gaps. Imperva still needs to do a better job of converting WAF customers to DB Security customers, and Application Security still needs to do a better job at holding onto the customers they already have. All this shows that the leader of this segment has yet to be determined, and there is a lot of potential business.
  3. One less vendor: Tizor went to Netezza. IPLocks went to Fortinet. Guardium went to IBM. Now Secerno to Oracle. That leaves Application Security and Imperva as the major database security providers out there, with Sentrigo the best of the smaller niche players in the market. EMC needs this technology next, perhaps followed by Symantec or McAfee, but the price of entry just increased.
  4. Investors: Secerno’s investors, Amadeus Capital Parners, must be happy. They did a logical reset and re-investment back in early 2008, a decision that was clearly the right one. They also had considerably less initial investment than the competitors in this space. While we do not know the actual purchase price, we are certain it will be lower than Guardium’s price, as Secerno’s revenues were lower.

What This Means to Users

  1. We all know what happens when a big company gobbles up a little one, and there should be no surprises here, because we’ve seen plenty of Oracle acquisitions.
  2. We believe Secerno will get additional R&D resources, and product integration isn’t a big issue due to how it’s designed in the first place. Secerno can run stand-alone for the foreseeable future.
  3. On the other hand, don’t be surprised if pricing and support contracts eventually increase.
  4. For existing Oracle customers, there may be an opportunity to get a price drop with initial bundling. You never know for sure, and this will skew toward bigger customers with more sway.

All in all this is a very good technology fit, and we think it will be a good business fit. We don’t say that just because it puts this product in front of Oracle’s sales force and channel partnerships. We know many of their customers went to Oracle first, looking for a compliance and security solution, and walked away dissatisfied. Oracle only needed to see Secerno eating its lunch so many times before doing something about it.

-Rich and Adrian

—Adrian Lane

Lessons from LifeLock’s Lucky 13

By Mike Rothman

Much of the buzz around the security industry this week revolved around Wired’s story about LifeLock’s CEO getting his identity stolen not once (which we knew about), but an additional 12 times. Guess 13 is not Todd Davis’ lucky number.

Obviously the media blitz posting this guy’s Social Security number on buses, TV, and other mass media made this guy target #1. And the reality is no identity protection network is going to be foolproof for a pretty simple reason. The companies issuing credit don’t always check for fraud alerts, so a fraud alert may not be triggered when a new account is opened. Even if you are religiously monitoring your credit, you are blind until the fraudulent account shows up where you can see it.

But what’s troubling to me is the guy didn’t know about the issues until a collection agency came after him. I’m concerned for several reasons, and the blame can be directed everywhere. First to LifeLock, how do you not see 12 new accounts? Hard to believe that none of the accounts showed up on Davis’ credit history. If not, what is the point of their identity protection service again?

Also note that none of the 13 transactions were for big numbers. A couple hundred here, a couple hundred there. That’s been my personal experience as well. The fraudsters don’t try to milk personal accounts of thousands at a time because that will set off alarms. They don’t want to be discovered until they are long gone.

More disturbing is how the merchants handle most of these situations. In the crazy search for growth at any cost, they cut corners. It’s as simple as that. They don’t check credit ahead of time (or they would have seen the fraud lock). They don’t report new credit accounts to the bureaus (which would have triggered a credit monitoring alert). And they don’t verify addresses when sending bills (which would have shown an inconsistency on the original application). Amazingly enough, a collection agent finds the guy within a hour, but the companies can’t do that over a year.

I guess I shouldn’t be surprised, since these big companies just build a ‘shrinkage’ number into their models. They figure a certain percentage of their customers will not pay, either for legitimate or fraudulent reasons. And I guess that’s cheaper than setting up the right processes to prevent a portion of that fraud. Ultimately it’s just economics, but it’s still very disturbing.

Buyt if I allowed myself to get into a funk every time a big company did something stupid and harmful, I’d be even grumpier than I already am. So I need to let that go. Though there are things we can and should do to minimize the damage of identity theft.

  • (Try to) Prevent it: OK, you can’t really prevent it. But you can act proactively to minimize your attack surface. That means setting up your own fraud alerts (since the credit bureaus and their lobbyists succeeded in killing the ability for a service to do this for you) and use a credit monitoring service (I use Debix, but there are lots out there).
  • Accept it: Understand that it will happen and there is likely nothing you can do. Getting upset won’t help. You need to be focused and contain the damage.
  • Contain it: As we always say, you need an incident response plan for your business in the event of a breach, but you need a personal incident response plan as well. Who do you call? What steps do you take? Those should be documented and in a place you can get to quickly. You need to act fast, and having a documented process reduces emotion and lets you make the decisions when you’re clear-headed and not rushing.
  • Confirm it: The credit bureaus are a hassle to deal with, but you have to stay on top of them to make sure your credit rating is properly cleaned. The three you need to worry about are Experian, Equifax, and TransUnion. That means checking your credit rating on an ongoing basis and keeping all documentation on the fraudulent use of your accounts.

Finally, don’t post personal information on the side of a bus. We know how that turns out.

—Mike Rothman

Wednesday, May 19, 2010

DB Quant: Planning Metrics (Part 4)

By Adrian Lane

This phase is for those of you using data classification and data labels. The Planning for Classification phase is where we determine our data classification scheme, map it to labels, and map those to access groups. If you have an existing classification scheme we’ll just map to that.

As a reminder, the process we originally specified was:

  1. Identify Requirements
  2. Specify Data Security
  3. Select Access Method
  4. Map to AAA
  5. Document

But as we talked it over we realized this was ambiguous and failed to capture the process. So we have simplified the process to:

  1. Determine Classification Scheme
  2. Map to Labels
  3. Map to Access Groups
  4. Document

Determine Classification

Variable Notes
Time to identify existing classification scheme
Time to adjust or develop scheme

Map to Labels

Variable Notes
Time to determine label techniques for DBMS platforms Labeling is implemented differently in the various database platforms. In some cases, implementation may need to be manual
Time to map labels to classification levels

Map to Access Groups

Variable Notes
Time to map groups to data labels Which groups from the AAA planning should be allowed access to data, by label

Document

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

Many of you may manage this on a per-application/database level, but we need to include this phase for those of you who adopt an enterprise standard.


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
  21. DB Quant: Planning Metrics, Part 3

—Adrian Lane

How to Survey Data Security Outcomes?

By Rich

I received a ton of great responses to my initial post looking for survey input on what people want to see in a data security survey. The single biggest request is to research control effectiveness: which tools actually prevent incidents.

Surveys are hard to build, and while I have been involved with a bunch of them, I am definitely not about to call myself an expert. There are people who spend their entire careers building surveys. As I sit here trying to put the question set together, I’m struggling for the best approach to assess outcome effectiveness, and figure it’s time to tap the wisdom of the crowd.

To provide context, this is the direction I’m headed in the survey design. My goal is to have the core question set take about 10-15 minutes to answer, which limits what I can do a bit.

Section 1: Demographics

The basics, much of which will be anonymized when we release the raw data.

Section 2: Technology and process usage

I’ll build a multi-select grid to determine which technologies are being considered or used, and at what scale. I took a similar approach in the Project Quant for Patch Management survey, and it seemed to work well. I also want to capture a little of why someone implemented a technology or process. Rather than listing all the elements, here is the general structure:

  • Technology/Process
  • Not Considering
  • Researching
  • Evaluating
  • Budgeted
  • Selected
  • Internal Testing
  • Proof of Concept
  • Initial Deployment
  • Protecting Some Critical Assets
  • Protecting Most Critical Assets
  • Limited General Deployment
  • General Deployment

And to capture the primary driver behind the implementation:

  • Technology/Process
  • Directly Required for Compliance (but not an audit deficiency)
  • Compliance Driven (but not required)
  • To Address Audit Deficiency
  • In Response to a Breach/Incident
  • In Response to a Partner/Competitor Breach or Incident
  • Internally Motivated (to improve security)
  • Cost Savings
  • Partner/Contractual Requirement

I know I need to tune these better and add some descriptive text, but as you can see I’m trying to characterize not only what people have bought, but what they are actually using, as well as to what degree and why. Technology examples will include things like network DLP, Full Drive Encryption, Database Activity Monitoring, etc. Process examples will include network segregation, data classification, and content discovery (I will tweak the stages here, because ‘deployment’ isn’t the best term for a process).

Section 3: Control effectiveness

This is the tough one, where I need the most assistance and feedback (and I already appreciate those of you with whom I will be discussing this stuff directly). I’m inclined to structure this in a similar format, but instead of checkboxes use numerical input.

My concern with numerical entry is that I think a lot of people won’t have the numbers available. I can also use a multiselect with None, Some, or Many, but I really hate that level of fuzziness and hope we can avoid it. Or I can do a combination, with both numerical and ranges as options. We’ll also need a time scale: per day, week, month, or year.

Finally, one of the tougher areas is that we need to characterize the type of data, its sensitivity/importance, and the potential (or actual) severity of the incidents. This partially kills me, because there are fuzzy elements here I’m not entirely comfortable with, so I will try and constrain them as much as possible using definitions. I’ve been spinning some design options, and trying to capture all this information without taking a billion hours of each respondent’s time isn’t easy. I’m leaning towards breaking severity out into four separate meta-questions, and dropping the low end to focus only on “sensitive” information – which if lost could result in a breach disclosure or other material business harm.

  • Major incidents with Personally Identifiable Information or regulated data (PII, credit cards, healthcare data, Social Security Numbers). A major incident is one that could result in a breach notification, material financial harm, or high reputation damage. In other words something that would trigger an incident response process, and involve executive management.
  • Major incidents with Intellectual Property (IP). A major incident is one that could result in material financial harm due to loss of competitive advantage, public disclosure, contract violation, etc. Again, something that would trigger incident response, and involve executive management.
  • Minor incidents with PII/regulated data. A minor incident would not result in a disclosure, fines, or other serious harm. Something managed within IT, security, and the business unit without executive involvement.
  • Minor incidents with IP.

Within each of these categories, we will build our table question to assess the number of incidents and false positive/negative rates:

  • Technology
  • Incidents Detected
  • Incidents Blocked
  • Incidents Mitigated (incident occurred but loss mitigated)
  • Incidents Missed
  • False Positive Detected
  • Per Day
  • Per Month
  • Per Year
  • N/A

There are some other questions I want to work in, but these are the meat of the survey and I am far from convinced I have it structured well. Parts are fuzzier than I’d like, I don’t know how many organizations are mature enough to even address outcomes, and I have a nagging feeling I’m missing something important.

So I could really use your feedback. I’ll fully credit everyone who helps, and you will all get the raw data to perform your own analyses.

—Rich

Symantec’s Identity Crisis

By Mike Rothman

After a year at the helm of Symantec, it seems Enrique Salem is taking a big page out of his predecessor’s playbook, basically buying everything that isn’t chained to the wall. The latest is a $1.28 billion deal to acquire VeriSign’s security business, which consists of the SSL and authentication arms.

The price seems fair, at about 4x revenue, so at least the Big Yellow is not overpaying, but so close on the heels of the encryption deals we really have to wonder about the timing. It’s hard to believe the VRSN security businesses were a hot commodity, requiring immediate action.

Before we dig into the issues let’s think about the strategy. Seems like Big Yellow is having a bit of an identity crisis. On the surface, like the PGP and GuardianEdge deals, the VeriSign authentication technologies fill a rather noticeable gap in SYMC’s product line. There are potential bundling opportunities for SSL with many of the suites already being sold, especially into the mid-market. And VeriSign never had the focus to broaden the product line, in order to really become an identity player. Symantec has the resources to continue building on this base and become an identity player. But making all this stuff work together would be a tall order for anyone.

As Rich pointed out in email, Symantec seems to be playing a lot of defense nowadays. The encryption deals were all about fending off McAfee, and now the VeriSign deal is about going after EMC. It’s hard to regain market leadership by fighting wars on multiple fronts. Part of averting the identity crisis is to more clearly communicate Symantec’s ultimate vision. That’s been shelved since the Veritas fiasco.

Now let’s take a look at the risks:

  • Integration risk: As we’ve mentioned before, Symantec’s forte has been doing deals, not doing deals well. And trying to integrate the encryption companies at the same time threatens to stretch an already thin management team way too thin.
  • Bundling risk: It’s not like anyone has really tried to bundle SSL certs or tokens with anything else. It’s always been a standalone business. And without some distribution leverage, they can’t make this deal pay.
  • Incumbent risk: VeriSign was the big dog in SSL, but in enterprise authentication they’ve largely struggled. Which makes this an unusual deal for Symantec, which tends to overpay for market leadership. The question is whether Symantec’s channel is willing to replace RSA, which may not be a stretch given EMC’s general channel unfriendliness.
  • Whole product risk: Symantec shouldn’t stop at authentication, but should use this as a platform for building a full identity offering. So that means looking at provisioning (Courion) and Federation (Ping Identity), or perhaps even another bold move to take Novell’s identity business.

Symantec has a history of chasing shiny objects, and this deal runs the risk of absorbing yet another company that then erodes without focus and execution. And given the accelerating commoditization of VeriSign’s core business, integration problems may very well kill the patient under the Big Yellow umbrella. Clearly identity is a key part of the enterprise security stack, but the worry is that Symantec is so distracted trying to gain territory from MFE and EMC/RSA that they go back to crappy execution on the cash cows.

—Mike Rothman

Incite 5/19/2010: Benefits of Bribery

By Mike Rothman

Don’t blink – you might miss it. No I’m not talking about my prowess in the bedroom, but the school year. It’s hard to believe, but Friday is the last day of school here in Atlanta. What the hell? It feels like a few weeks ago we put the twins’ name tags on, and put them on the bus for their first day of kindergarten.

Just take it... The end of school also means it’s summertime. Maybe not officially, but it’s starting to feel that way. I do love the summer. The kids do as well, and what’s not to love? Especially if you are my kids. There is the upcoming Disney trip, the week at the beach, the 5-6 weeks of assorted summer camp(s), and lots of fun activities with Mom. Yeah, they’ve got it rough.

Yet we still face the challenge of keeping the kids grounded when they are faced with a life of relative abundance. Don’t get me wrong, I know how fortunate I am to be able to provide my kids with such rich experiences as they grow up. But XX1 got our goats over the weekend, when one of her friends got an iPod touch for her birthday. Of course, her reaction was “Why can’t I have an iPod touch, all my friends have them?”

Thankfully the Boss was there, as I doubt I would have responded well to that line of questioning. She calmly told XX1 that with an attitude like that, she’ll be lucky if we don’t take away all her toys. And that she needs to be grateful for what she has, not focused on what she doesn’t.

To be clear, not all of her friends have iPod touches. She is prone to exaggeration, like her Dad. What she doesn’t know is our plan to give her a hand-me down iPhone once we upgrade this summer. (Of course I’m upgrading, come on, now!) I think we need to tie it to some kind of achievement. Maybe if she works hard on her school exercises over the summer. Or is nice to her sister (yes, that is a problem). Or whatever kind of behavior we want to incent at any given time. There’s nothing like having a big anchor over her head to drag out every time she misbehaves. That’s right, it’s a bribe.

I’m sure there are better ways than bribery to get the kids to do what we want. I’m just not sure what they are, and nothing we’ve tried seems to work like putting that old carrot out there and waiting for Pavlov to work his magic.

– Mike.

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


Incite 4 U

  1. Where is the Blog Love? – I’m going to break the rules and link to one of my own posts. On Monday I called out the decline of blogging. Basically, people have either moved to Twitter or left the community discussion completely. Twitter is great, but it can’t replace a good blog war. In response, Andy the IT Guy, DanO, and LoverVamp jumped back on the scene. These are 3 sites I used to read every day (and still do, when they are updated) and maybe we can start rebuilding the community. Why is that important? Because blogs provide a more nuanced, permanent archive of knowledge with more reasoned debate than Twitter, however wonderful, can sustain. – RM

  2. Critical Infrastructure Condition Critical – We all take uninterrupted power for granted. Yet, we security folks understand how vulnerable the critical infrastructure is to cyber-attacks. Dark Reading has an interesting interview with with Joe Weiss, who has written a book about how screwed we are. A lot of the discussions sound very similar to every other industry that requires the regulatory fist of God to come crashing down before they fix anything. And NERC CIP is only a start, since it exempts the stuff that is really interesting, like networks and the actual control systems. Unfortunately it will take a massive outage caused by an attack to change anything. But we all know that because we’ve seen this movie before. – MR

  3. Desktop, The Way You Want It – I am a big fan of desktop virtualization, and I am surprised it has gotten such limited traction. I think people view it ass backwards. The label “dumb terminal” is in the back of people’s minds, and that not a progressive model. But desktop virtualization is much, much more than a refresh of the dumb terminal model. The ability to contain the work environment in a virtual server makes things a heck of a lot easier for IT, and benefits the employee, who can access a fully functional desktop from anywhere inside – and possibly outside – the company. Citrix giving each employee $2,100 to buy their own computer for work is a very smart idea. The benefits to Citrix are numerous. Every employee gets to pick the computer they want, for better or worse, and they are now invested in their choice, rather than considering a work laptop to be a disposable loaner. The work environment is kept safe in a virtual container, and employees still get fully mobile computing. Every user becomes a tester for the company’s desktop virtualization environment, bringing diverse environments under the microscope. And it shows how they can blend work and home environments, without compromising one for the other. This is a good move and makes sense for SMB and enterprise computing environments. – AL

  4. Security 5.0 – HTML5 is coming down the pipe, and Veracode has some great advice on what to keep an eye on from a security perspective. Not to show my age, but I remember hand-coding sites in HTML v1, and how exciting it was when things like JavaScript started appearing. Any time we have one of these major transitions we see security issues crop up, and as you start leveraging all the new goodness it never hurtss to start looking at security early in the process. Odds are your developers are already using bits and pieces of it anyway… especially if they are coding for the iPhone/iPad. – RM

  5. DPI Behind the Scenes – I eyed Will Gragido’s post about deep packet inspection (DPI) as a next generation technology with bemusement. First because I hate the term next generation. But Will kind of misses the point here. Folks are resistant to new technology, but they are not resistant to solving their problems. DPI is not a product you buy, but a way to solve a number of problems – ranging from security enforcement, to network performance management, to content inspection. Who cares if anyone resists a particular name? They are not resistant to understanding what is happening on their networks, so they need some form of DPI. Just don’t call it DPI and we’ll be all good. – MR

  6. Cyber-Security and National Policy – Dan Geer does it again: Cybersecurity and National Policy. As usual from Dan, this is (to say the least) dense, and covers a broad range of topics. One favorite is: “To this extent, security becomes a subset of reliability in that an insecure system will not be reliable, but a reliable system is not necessarily secure.” Bonus: this fuels the rumor that Hoff is in fact Dan in disguise. – DMort

  7. Employees Look out for #1? Really? – The jackass survey of the week award goes to Trend Micro, who actually published the stunning fact that Employees Put Personal Security, Interests Above Company’s. And Dark Reading actually went with the story. Given the loyalty that most companies show their employees nowadays, why is this a surprise? Even better, 1 in 10 users go around corporate security to access restricted websites. Really, truly? All I can say is I hope they didn’t pay a lot for that survey. – MR

  8. Auditor School – Are you an auditor? Do you deal with auditors? How about “assessors” – you know, auditors who don’t want the title, because they think it’s not nice – or because it creates too much legal liability? If so, this post at Layer8 is mandatory reading. Shrdlu (who, as an end user, has to deal with them all the time) presents an open letter to auditors that should be part of every engagement. The audit process is bad enough without someone calling for last-minute meetings without a defined agenda, or blasting out random emails instead of structured documentation. Auditors are just as fallible as the rest of us, and setting expectations early can sure ease the process. – RM

  9. Back-Handed Compliments – Over on the CSO Online site, Bill Brenner posted an opinion piece on Rugged software. He makes a comparison between the data security features in the Oracle database, and software development principles that have yet to be fully defined. WTF? “Unbreakable” was marketing run amok, with product function falling far short of claims, giving Oracle a long lasting black eye. Bill is relating the two concepts, saying he is more comfortable with Rugged, as it implies “… a toughness that’s a lot better than what came before.” That is a little like saying Rugged doesn’t suck as much. Saying “Your new car is better than a Yugo,” is not a compliment. Of course “… rugged isn’t something you can contain in a box” is a correct statement. That’s because there is nothing to put in the box! Not yet anyway. Look, I admire what Josh Corman is doing over at 451 Group with Rugged. It’s the right idea. The real question is: What are the next steps to make Rugged more tangible? Pragmatic, actionable advice and recommended techniques are in order, as this conceptual blob tries to morph into useful approach. Bill’s getting the word out about Rugged, but frankly, the community is still on the fence, and will remain that way until there is something of substance for us to chew on. Comparing a bad marketing idea with Rugged principles achieves little more than kicking Oracle for a decade-old mistake. If we want to do something useful, let’s talk about how MS SDL is or is not Rugged, or contrast Rugged concepts with BSIMM. Those discussions would be much more interesting! But that sends chills down developers’ spines. The problem is that many in the secure code movement have trepidations about saying anything bad about any secure code practices, as the ideas are just now gaining momentum. But we have to go there at some point to make Rugged real. – AL

  10. Do They Have a Class for Common Sense? – Raf hits the nail on the head here, giving some career advice to security folks. The reality is that security is much less of a technical discipline than any other IT function. Sure, there is some level of kung fu that you need to get things done, but ultimately it’s about people. Security folks have to convince IT peers that security is important, and employees not to do stupid things. Many of these tactics depend on a level of business savvy and understanding of how to get things done in their specific organizations. As Raf says: “There is a distinct lack of the analytical mind, business-level understanding and even worse …common sense.” Unfortunately those aren’t skills you can teach – not in a SANS class, anyway. So we’ll end up with a glut of adequate technical folks and a distinct lack of leaders. Which makes us like every other technical discipline, I guess. – MR

—Mike Rothman

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