Category: Uncategorized

Speed is vital, so the time may be right to assemble a forensic SWAT team trained to locate high-risk threats, armed with the latest investigative software, and empowered to work directly with legal counsel to report breaches in accordance with policy.

Acquiring evidence in a forensically sound manner isn’t difficult with the proper tools and training, but policies and procedures must be put in place that ensure the repeatability, accuracy, completeness, and verifiability of evidence as proscribed by the Federal Rules of Evidence. In addition to clearly written policies, there must be a forensic methodology that’s followed for acquiring, handling, and analyzing evidence.

AccessData, Guidance Software, and Mandiant are at the forefront of producing enterprise versions of robust, collaborative incident-response and forensic tools. Both AccessData’s and Guidance Software’s suites allow for remote access to computers so investigators can retrieve details from running systems. Mandiant’s Intelligent Response has comparable capabilities but is more focused on incident response. Agile’s F-Response product allows investigators to mount Windows hard drives and physical memory remotely and in a read-only manner so they can perform forensically sound “live” analysis of running Windows systems. The remote systems’ hard drives and physical memory appear as normal attached drives to the investigator’s system, allowing IT to use any forensic product for analysis.

Every enterprise forensic tool has added memory imaging capabilities in the past 12 to 18 months, with varying capabilities for in-depth analysis of acquired images.

The Volatility Framework is an open source tool leading the way with its ability to list running processes, open network ports, and files opened and DLLs loaded by each process; it can also extract executables from memory for further analysis.

http://www.informationweek.com/news/security/management/showArticle.jhtml;jsessionid=BRQVSY1YF4EB4QSNDLPCKH0CJUNN2JVN?articleID=211600249

The Verizon report is a collective analysis of some 530 forensic investigations of data breaches that the company has done in large enterprises. It breaks down the causes of the breaches by industry and draws conclusions about the most common types of attacks committed in each.

In financial services, for example, Verizon investigated many sophisticated attacks involving cooperation of insiders and organized outsiders, as well as social engineering. In the food and beverage industry, on the other hand, the attacks were much less sophisticated, and the likelihood of internal attacks was only about 4 percent, while the likelihood of external and partner attacks was 70 percent to 80 percent. “In food and beverage, though, we saw a lot more repeatable, data-compromise-in-a-box sort of attacks — sort of the way…” Verizon found similar differences in the sophistication and approaches used to attack data in other industries, including retail and high technology.

Retail, for example, reported the highest number of breach incidents, but a relatively low level of attack sophistication.

What these results might mean, Sartin says, is that employing a generic risk calculation, such as the likelihood of insider threats, may be a mistake unless industry-specific factors are accounted for.

http://www.darkreading.com/document.asp?doc_id=165107&WT.svl=news2_3

With the Computer Security Institute reporting that 46 percent of computer security professionals have had security incidents in the past year, 26 percent of which have had more than 10, you begin to see the magnitude of the problem.

Sixty-five percent of this cost is the direct result of lost business, including customer termination—a rate that is increasing by 30 percent a year.

All this amounts to an unpleasant picture, one where current practices in breach response are falling short in keeping your customers, and therefore revenue, within your company.

Legal obligation vs. Customer satisfaction Recent research by the Ponemon Institute, the Consumers’ Report Card on Data Breach Notification, has provided some of the most useful information to date to help organizations determine the most effective techniques to minimize the impact of a breach and to retain customers. Large delays in notification signal to your customers that you are hiding something and/or they are not important to you, despite some realities that it takes time to assess the impact of a breach. Although it may not be possible to notify customers within a week, or even several weeks following a breach, your goal should be to notify them as soon as possible, with what reasonable information you can divulge at that time.

Do they have to close their credit card accounts? Many respondents in the Ponemon study found communications to be unbelievable or misleading, failing to reduce their fears about potential harms they faced because of a breach. Although you are the barer of bad news, you also have the opportunity to be the barer of solutions. Lay out for your customers the “next steps” they can or need to take after they are notified. Include information, phone numbers and Web sites on freezing credit files, getting free credit reports and other tips customers might want to know and follow.

At little or no cost to your organization, acting as an educator will not only help your customers recover from the incident, but maintain your organization as a trusted source.

Offering identity protection services has proven to have a positive effect on customer retention, and in many cases, offering such services is more affordable than new customer acquisition strategies. Individuals who receive free or subsidized services, such as credit monitoring, identity theft insurance or identity recovery services, feel less concerned and worried about the breach after it happens.

http://www.csoonline.com/article/451785/How_to_Minimize_the_Impact_of_a_Data_Breach?source=nlt_csoupdate

All storage, structured or unstructured, requires security of some kind, even if it’s simply flipping an on/off switch or pulling the USB plug on a direct-attached external disk. Database storage security, the subject of this article, can be slightly more complicated than that.

I talked recently with Ted Julian, vice president of consultancy Application Security, about the often-thorny security issues surrounding structured content in databases. Julian drew up a detailed look, in several steps, at what he sees as important in database security, starting with data discovery and moving all the way through how to implement intrusion detection.

First of all, you need to know exactly what you are securing. “This is perhaps one of the easiest, yet most critical, steps in getting started in protecting your data—knowing where it is,” Julian said. “The point being that, if you are looking to shore up protection against attacks on your data, if you aren’t sure where that data resides, chances are that it’s not currently protected. Once you can establish where your databases are residing within your environment, you can get started on assessing your overall environment and taking an inventory of your data assets.”

Julian said database administrators need to inventory all databases, identify the vulnerabilities that are present and create a baseline of current security assets for ongoing comparison. The ability to track and monitor progress is an important component of most compliance initiatives. This process will help organizations identify common flaws, including unpatched systems, weak or default passwords, excessive privileges and a lack of system monitoring. The task can be streamlined by utilizing technological solutions to assist with discovery, to establish a security posture baseline and to generate fix scripts to speed along remediation. A complete database security solution will also include policies to monitor for threats and vulnerabilities in real time, Julian said.

DBAs need to prioritize their most pressing issues up front. “Comprehensive database security efforts are based on vulnerability and threat data, including vulnerability severity and the criticality of the database information,” Julian said. “Once priorities are documented, an organization should to enact a formal security plan, report on progress and demonstrate ongoing improvement.”

In order to mitigate risk and improve the database security posture, the next step in shoring up security at the database level is to fix or remediate known vulnerabilities. Software patches and known workarounds should be applied. “Not all vulnerabilities can be eliminated or patched immediately.

Customized policies and real-time alerting on suspicious activities allows an organization to proactively respond to threats,” Julian said. According to Julian, Application Security’s Database Security Lifecycle methodology allows enterprises to extend layered defenses to the repositories of their most critical and confidential information and as a result significantly minimize security risk.

These steps are an important component of any compliance effort; they enable organizations to respond promptly and provide informed remediation and notification when necessary, he said.

Here are some basic database security steps enterprises can take that will improve their database security postures in just one day. Every database Oracle has ever shipped has come with a set of default accounts and passwords. These user names and passwords are well known and documented. “Default passwords are problematic, because they leave the front door to your database wide open,” Julian said. There are currently over 600 known default user name and password combinations and probably a dozen free tools to scan for them, Julian said. By the way, Oracle11g includes a built-in DBA view to list default passwords (DBA_USERS_WITH_DEFPWD). One of the most common attack vectors to this day is access via passwords that can be easily guessed. Passwords should be eight or more characters in length; 14 characters or longer is ideal. A 15-character password composed only of random letters and numbers is about 33,000 times stronger than an eight-character password that uses characters from the entire keyboard.

A crucial element of securing the database is to ensure that patches are implemented in a timely manner and known vulnerabilities are monitored in real time. Automate security tasks as a regular part of database maintenance. So much of security relies on regular assessments and validation; the day-to-day work can quickly decline into tedium and get overlooked. Utilizing software that provides regular security updates for patches, new threats and known vulnerabilities is essential to protecting the database and containing risk.

Protecting data at its source, the database, is essential to preventing breaches and data loss. Even with traditional perimeter security measures in place, the best way to defend against data harvesting (where attackers remove or damage large amounts of data) is to rely on a layered defense model that necessarily includes the database.

http://www.eweek.com/c/a/Data-Storage/Keys-to-Locking-Down-Storage-Security-on-a-Database/?kc=rss

At the same time, it’s likely you won’t have thought of everything or implemented defenses against every possible attack. It’s very unlikely you have a home defense management plan or have ever run a penetration test against your home.

As we build software, regardless of whether we’re in an agile or a waterfall world, we need agreement on what we’re building, what we’re not building, and what we’re doing to ensure we’re building the right thing. In the past few years, a perception that threat modeling is a heavy, bureaucratic process has been generated. There are some good reasons to move toward adding processes; I’d like to talk about them, some lessons learned from these processes, and how to put the fun back in threat modeling while making it an efficient, agile-friendly activity that anyone can do.

Approaches to Threat Modeling
There are many things called threat modeling. Rather than argue about which is “the one true way,” consider your needs and what your skills, abilities, and schedules are, and then work with a method that’s best for you. As part of that approach, some people ask, “What’s your threat model?” and “Have you threat modeled that component?”

One is requirements elicitation, the other design analysis. At Microsoft, we almost always mean the latter technique. There are more threat modeling methods out there than I can dream of covering in one column. There’s also a tremendous diversity of goals. Should your threat modeling process be fast or deep? Should it focus on assurance and completeness, or ease of use? Should you involve experts or developers in every meeting? Do you have organizational or industry rules you need to follow, such as the Microsoft® Security Development Lifecycle (SDL) or the rules for medical device manufacturers?

The high level objective should be to understand security issues early so you can address them in the design rather than try to overcome design flaws later. Some of the major ways to approach threat modeling activity include the following:

Assets
Asset-driven threat modeling is much like thinking about what you want to protect in your house. You start by listing what assets your software has associated with it, and then you think about how an attacker might compromise those assets. Examples include a database that stores customer credit cards or a file that contains encrypted passwords. Some people may interpret an asset as an element of the threat modeling diagram, thinking that a Web server itself is an asset. Digital assets are things an attacker wants to read, tamper with, or deny you the use of.

Attackers
Attacker-driven threat modeling involves thinking about who might want your assets, and it works from an understanding of their capabilities to an understanding of how they might attack you. This works great when your adversary is a foreign army with a known strategic doctrine, physical world limits, and long-lead-time weapons systems development. This works less well when your adversary is a loosely organized group of anonymous hackers. More generally, it’s not clear this is useful in software threat modeling. There are certainly people for whom “think like an attacker” is an effective part of design analysis. It’s less clear that this is a reproducible process in which people can get training. If you’re going to start from attackers, it’s probably worth using a standard set. It will be helpful to have a small set of these anti-personas written out.

Software Design
Design-driven threat modeling is threat modeling based on where your fences and windows are. You draw diagrams and worry about what can go wrong with each thing in your diagram. (This is the essence of the SDL threat modeling process today because everyone in software knows how to draw diagrams on a whiteboard.) The software equivalents of fences and windows are the various forms of attack surface, such as file parsers or network listening services—sockets, remote procedure call (RPC) services, Web services description language (WSDL) interfaces, or AJAX APIs. They’re the trust boundaries where you should expect an attacker to first get a foothold.

A Quick and Dirty Threat Model
Threat modeling doesn’t have to be a chore. Following the process illustrated in Figure 1, here is the outline of a basic threat modeling process that will get you going quickly and painlessly: Diagram your application, and use this to tell your app’s story in front of the whiteboard (see Figure 2). Use circles for code, boxes for things that exist outside of it (people, servers), and drums for storage. Our team uses funny looking parallel lines for data stores. Draw some trust boundaries using dotted lines to distinguish domains. When you get stuck, apply the STRIDE threat model, described in Figure 3, on each element of your app. All the threats in one place may mean you’re worried about the front door and not worrying about anything else. A third order defense might be an alarm system on the door, and to mitigate the threat of someone cutting the wire, you send a regular message down the wire. If you find yourself worrying about the software equivalent of what happens when someone cuts the phone wire to the alarm system before you worry about locks on the doors, you’re worrying about the wrong things.

File bugs so you can fix what you found threat modeling. Modifying a DLL on disk or DVD, or a packet as it traverses the LAN. Allowing someone to read the Windows source code; publishing a list of customers to a Web site. Crashing Windows or a Web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole. Elevation of Privilege Authorization Gain capabilities without proper authorization.

Finally, you need to account for the availability of time and resources both for your threat modeling process and any resulting mitigation and testing.

Microsoft has found that threat modeling works better with a security expert in the room, but there isn’t always one available. You can get decent results by giving people structure and feedback on their work, and by breaking it down into small, easy pieces with rules and self-checks in each one. For problems validating the threat model and your mitigation plan, look to see whether the diagrams represent the code and whether you have agreement between developers and testers on that.

http://msdn.microsoft.com/en-us/magazine/cc700352.aspx

How do you justify spending on something that isn’t designed to increase the bottom line? The fear factor exists, and yet explaining why bulletproof glass is worth more than Plexiglas still requires numbers. With a recession hovering over the United States like some black helicopter, there will be still more pressure to measure what security spending brings to a company.

One big challenge is that the data rarely is simple to pull together. And even though there are now tools like Agiliance, which makes an ROI calculator for information security expenditures, the devil is still in the data.

Here are four well-known metrics and measurement components that, if used properly, can help put the impact of security spending in the financial perspective companies need.

ROI (Return on Investment) It’s a classic business expectation that if you invest money in something, you can measure the return on your investment by its impact on the bottom line. But understanding the value of security spending presents challenges, since the tension that exists in most branches of IT is that investment does not usually lead directly to profits. For security spending, the problem is bigger: If investing in security works, nothing happens.

But what if nothing would have happened anyway?

“[The trouble with] trying to calculate ROI on security tools is that they destroy the proof of their effectiveness simply by doing their job,” says Ross Leo, CEO of Alliance Group Research, a security consultancy. So ROI has become a somewhat loose measure of how long it will take to recoup the cost of investing in security. It is not a perfect measure, which may be why its usage appears to be dropping.

Some 42 percent of organizations polled in the 2007 Computer Security Institute Computer Crime and Security Survey said they used ROI to measure their information security investments. That was up from 39 percent the year before, but well below the 55 percent who reported using it in 2004.

Other common measures: 21 percent of respondents said they used internal rate of return measures, and 19 percent used net present value. ROI can be straightforward for some aspects of physical security. Craig Chambers, CEO of Cernium, which makes software that analyzes videotape, says at a minimum, his firm’s tools mean companies can hire fewer security guards, creating obvious savings on salary and benefits. But it’s rarely so straightforward to calculate savings. Some of the problems with using ROI: Strict adherence to ROI may cause companies to pick the wrong technology to save money. For instance, a firm might find that inexpensive surveillance cameras are not as effective as ones that include built-in analytical tools, but a strict focus on ROI will seem to show a better payback for an inferior product, says Steve Hunt, a security consultant in Evanston, Ill. “ROI is misleading because people don’t understand what they’re trying to accomplish…Look at the benefit you want first, then the ROI,” Hunt says. He doesn’t think ROI numbers work well in security, and he tends to counter with a discussion of their likely losses if they don’t invest in security services. Even though he prefers measuring losses, he concedes that unless a firm has recently experienced a breach of some sort, measuring costs becomes an exercise in “throwing darts at a dartboard.”

Otherwise, it’s tough to quantify the potential around losses, says Anthony Hernandez, managing director of the information risk management practice at Smart business advisory and consulting in Devon, Pa. He notes, for instance, that it was difficult to say what companies would get in return for spending on HIPAA compliance. In the case of PCI, he’s seeing companies receive fines of $25,000 a month. It’s also possible to measure what breaches will cost, thanks in part to incidents like those at TJX, which paid $100 million in fines and another $156 million to resolve lawsuits. It would be harder to say whether TJX suffered any intangible costs, like loss of goodwill (sales actually rose in the wake of the breaches).

Note that there’s also another measure, ROSI (return on security investment), which works by taking the expected security spending and subtracting any expected annual loss (see ALE, Page 39).

TCO (Total Cost of Ownership) An alternative to ROI is to figure the total cost of ownership (TCO) for a security investment. While the purchase cost or ongoing contract costs will be clear, figuring out less-obvious spending is harder. For Tyminski, TCO helped him justify buying a new intrusion prevention system. Bell will measure the time system administrators need to spend with the product, how much time it will take to install or migrate to a software package, what the product itself costs (both up front and for maintenance or support) and how much time its help desk will spend doing hand-holding. Marc Shapiro, senior vice president of Group 4 Securicor, the parent company of Wackenhut, says the firm is seeing more CSOs look for metrics, primarily TCO. Ideally, he likes to contrast those with the potential losses, but even in the physical security world, annualized loss estimates “are difficult to get,” he says.

EVA (Economic Value Added) The best-known version of EVA was developed and trademarked by Stern Stewart and offers a way to measure financial performance for business units. To use an EVA in a practical way, one should take numbers used to generate things like total cost of ownership, ROI and the annualized loss expectancy, and compare them to actual costs, looking at factors like what it would cost to implement and support them.

http://www.csoonline.com/article/394963/Security_and_Business_Financial_Basics