Tag Archives: application

The 3:00 A.M. Incident Response Phone Call − A Success Story

It’s 3:00 A.M., and you receive the dreaded IR phone call. Your CSO is demanding an immediate response to an attack on your company’s resources. Dreary and lethargic, you stumble out of bed and VPN into your network. You pull up your centralized log management and see that there have been literally thousands of requests to your website in the span of time that typically sees between 50 and 100 requests. You feel your heart rate pick up, your palms get damp….

You’re under attack.

You begin rummaging through your network changelogs for the past twenty-four hours, attempting to see if there have been any major changes to the infrastructure or major software roll-outs across the network. But you find there have been no network changes, and no previously unvetted software updates have been pushed. “Damn,” you mutter to yourself, “if only the problem were that easy to identify….”

Your fingers flash across the keyboard in a rush as your Chief of the Network Operations Center floods your instant messenger with requests for updates.

C-NOC: “I guess since you’re up at this ungodly hour, CSO has you running IR for the breach?”

Me@3: “Yeah, any word from the network side? Hopefully we’re not seeing any data exfiltration from internal, right?”

C-NOC: “No, just a metric ton of smtp requests coming from the log management…. What alert controls did you have in place in case of an attack?”

Me@3: ”Crap, sorry  John, guess I forgot to put the alert mail cap in place…wait a second, I have to go, John. I totally forgot to check one of the most obvious things!”

C-NOC: ”Ha, you forgot to check the WAF? Noob :P

{C-NOC John has disconnected}

You have to love an environment where even the most severe problems result in good-hearted ribbing between colleagues.

You quickly surf to the URL where your WAF typically resides, and find the elegant interface filled with thousands of requests, which appear to be the result of someone running a fuzzer against the account information pages. It seems as if someone is attempting to SQLmap to iterate through all possible injections.

You laugh maniacally to yourself and lean back in your office chair, thoroughly satisfied with your department’s preparations for this very problem.  Just three weeks ago, you completed the transition from raw user interaction with the SQL database to a more secure parameterized transaction. As you pour yourself a bowl of cereal, you begin mentally drafting the incident report to your boss.

It’s going to be a good day.

An Incident Is a Terrible Thing to Waste (even those of others)

Hacks happen. The data captured by Verizon’s Data Breach Investigations Report, DataLossDB, and WASC’s Web Hacking Incident Database make this reality painfully obvious. The summary is most incidents, and the bulk of the data lost, is a direct result of vulnerable Web applications being exploited. As further evidence, Forrester’s 2009 research reported, “62% of organizations surveyed experienced breaches in critical applications in a 12 month period.” Dasient, a firm specializing in web-based malware, said “[In 2011] The probability that an average Internet user will hit an infected page after three months of Web browsing is 95 percent.”

These resources and the compromises of Apache.org, Comodo, Gawker, HBGary Federal, MySQL.com, NYSE, Sun.com, Zynga, and countless others are a good excuse to have a conversation with management about your organization’s potential risks.

Despite the facts, the idea of getting hacked is not often a conscious thought in the minds of executives, so of course it’s only a matter of time before the business becomes another statistic. When this happens and the business is suddenly awakened from a culture of security complacency, all eyes will become focused on understanding exactly what happened, why it happened, and how much worse it could have been. In the aftermath of a breach, employee dismissal and business collapses are rare, more often than not security budgets are expanded. Few things free up security dollars faster than a compromise, except for maybe an auditor.The security department will have the full attention of management, the board, and customers who all want to know what steps are being taken to ensure this never happens again. Post breach is an excellent time to put a truly effective security program in place, not just built around point products, but designed around outcomes and to have a lasting impact.

PROTIP: Security as a Differentiator

Update: The counter point, Security is rarely a differentiator, via Mike Rothman (@securityincite)

Every company needs a competitive advantage, the more the better, and “security” can be a powerful differentiator. This is because security is very important to people and is becoming more so with each passing day of computer-hacking-privacy-invading headlines and virus infected PCs. People need and want to be able to trust those who ask for their names, contact details, email, social security numbers, health information, payment data, and so on. When security is made visible (i.e. help customers be and feel safe), the customer may be more inclined to do business with those who clearly take the matter seriously over others who don’t.

“Making security visible” can be achieved through offering strong and flexible security controls, documentation about a comprehensive infosec program, recent audit reports conducted by an independent third-party, contractual SLAs, etc. As an information security professional, imagine being able to ask for budget to do these things and more by saying to a CxO, “If we invest $A on B (security thing), our sales & marketing department research estimates an increase in new customers and financial upside of $C.” As long as C is great then A, then you have a strong business case.

All of sudden security budgets go from being perceived as a unavoidable cost of doing business, where the goal is to spend the least amount of dollars possible, to a vehicle that drives revenue. Nothing beats that! To get there security pros must engage with sales and marketing personnel, and of course customers and prospects, to see how often “security” is a buying criteria. Understand what customers want and the premium value potentially applied to the sale. Successful efforts result in an excellent opportunity to align with the business objectives and everybody wins.