When a data owner's (a business) sensitive data is breached it is difficult to quantify the monetary loss. According to respectable survey sources, the average cost of sensitive data breach for a large size company is about $50,000. I am attempting here to think about this in simple mathametical terms:

There is a data breach. From the data owner's perspective the loss is:

Loss = Cost to protect data + Loss of business due to data theft aka cost of competitive disadvantage

From the data thief's perspective

Net Gain= [Cost of producing the data  *  Data freshness factor] - Cost to steal the data + Profit of business due to data aka gain of competitive advantage

From the above two equations it is very clear that this is not a zero sum game. There is a clear cost asymmetry for a data owner and for a data thief. When there is an asymmetry there is an opportunity. Data owner would not even know that the data is lost because the original copy of the data may be still intact - data thief could have simply copied the data. Data theft does not look like a car theft, there is no vacuum left behind. 

This motivates a data thief to keep the cost to steal low, steal highly valuable data that has a long shelf life and in a way that data owner will never even be aware of theft.

From a data thief's perspective, the cost to steal data if kept high would disincentive him. Moreover, Data freshness factor, i.e. how valuable this data is over period of time plays an important role. A good example is content of today's newspaper is hardly valuable tomorrow, but the content of newspaper two days ahead (if can be procured)would be invaluable. Data relevance is a function of time and other marketplace variables -  Data freshness Factor accounts for that variable. A good way to discourage data thief is to increase his/her cost to steal the data. There are other inferences from the above equation. If there exists no competitive advantage with the stolen data, hardly any thief would even venture to steal the data in the first place. If the cost of producing data is very low, then probably thief can just produce the data himself and would not attempt to steal the data. If the cost of theft is kept high, it would definitely deter the data thief from stealing data using technical mechanisms, then the data thief would exploit weak links in data security such as use of social engineering to get access to the data.

From data owner perspective protecting data becomes very important. How much would the owner be willing to spend? Not definitely the cost equal to cost of producing the data. 1% to 10% of cost of producing data is considered prudent. For a data owner it is difficult to estimate cost of data protection of a specific data, because it is not easy to chunkify data protection costs. Moreover, as Dan Geer says in his book, a data owner has to protect himself from number of intruders not just one.

It pays for a data owner to: be aware of data breaches (or data leaks), employ appropriate mechanisms to protect the data; the cost of protection which is fractional cost of the valuable data and enhance information security awareness of personnel who handle the data.

Data loss is not a zero sum game. The advantage is in favor of a data thief (data thieves rather). Data owner does not give much thought on the value of data unless there is a data theft. But, a data thief has every reason to think about economics of data theft before he acts to steal the data else data thief won't survive in this game and he is very well aware of his advantageous position.

Formalize Requirements for long-term use

Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.

At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies.  Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.

Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version.  Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.

I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.

Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.

Reference & Reuse Threat Modeling results & Attack Surface Reviews

Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:

·         Think about component-level architecture

·         List common pitfalls in writing code, or begin defining and building test cases.

·         Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.

·         Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.

·         Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.

Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.

I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.

Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.

In the meantime, we’d like to hear from you:

?        How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?

?        What challenges have you faced in enforcing requirements across your teams?

?        How have you implemented threat models or attack surface reviews?

In 1993, Internet pioneer John Gilmore said "the net interprets censorship as damage and routes around it", and we believed him. In 1996, cyberlibertarian John Perry Barlow issued his 'Declaration of the Independence of Cyberspace' at the World Economic Forum at Davos, Switzerland, and online. He told governments: "You have no moral right to rule us, nor do you possess any methods of enforcement that we have true reason to fear."

At the time, many shared Barlow's sentiments. The Internet empowered people. It gave them access to information and couldn't be stopped, blocked or filtered. Give someone access to the Internet, and they have access to everything. Governments that relied on censorship to control their citizens were doomed.

Today, things are very different. Internet censorship is flourishing. Organizations selectively block employees' access to the Internet. At least 26 countries -- mainly in the Middle East, North Africa, Asia, the Pacific and the former Soviet Union -- selectively block their citizens' Internet access. Even more countries legislate to control what can and cannot be said, downloaded or linked to. "You have no sovereignty where we gather," said Barlow. Oh yes we do, the governments of the world have replied.

Access Denied is a survey of the practice of Internet filtering, and a sourcebook of details about the countries that engage in the practice. It is written by researchers of the OpenNet Initiative (ONI), an organization that is dedicated to documenting global Internet filtering around the world.

The first half of the book comprises essays written by ONI researchers on the politics, practice, technology, legality and social effects of Internet filtering. There are three basic rationales for Internet censorship: politics and power; social norms, morals and religion; and security concerns.

Some countries, such as India, filter only a few sites; others, such as Iran, extensively filter the Internet. Saudi Arabia tries to block all pornography (social norms and morals). Syria blocks everything from the Israeli domain ".il" (politics and power). Some countries filter only at certain times. During the 2006 elections in Belarus, for example, the website of the main opposition candidate disappeared from the Internet.

The effectiveness of Internet filtering is mixed; it depends on the tools used and the granularity of filtering. It is much easier to block particular URLs or entire domains than it is to block information on a particular topic. Some countries block specific sites or URLs based on some predefined list but new URLs with similar content appear all the time. Other countries -- notably China -- try to filter on the basis of keywords in the actual web pages. A halfway measure is to filter on the basis of URL keywords: names of dissidents or political parties, or sexual words.

Much of the technology has other applications. Software for filtering is a legitimate product category, purchased by schools to limit access by children to objectionable material and by corporations trying to prevent their employees from being distracted at work. One chapter discusses the ethical implications of companies selling products, services and technologies that enable Internet censorship.

Some censorship is legal, not technical. Countries have laws against publishing certain content, registration requirements that prevent anonymous Internet use, liability laws that force Internet service providers to filter themselves, or surveillance. Egypt does not engage in technical Internet filtering; instead, its laws discourage the publishing and reading of certain content -- it has even jailed people for their online activities.

The second half of Access Denied consists of detailed descriptions of Internet use, regulations and censorship in eight regions of the world, and in each of 40 different countries. The ONI found evidence of censorship in 26 of those 40. For the other 14 countries, it summarizes the legal and regulatory framework surrounding Internet use, and tests the results that indicated no censorship. This leads to 200 pages of rather dry reading, but it is vitally important to have this information well-documented and easily accessible. The book's data are from 2006, but the authors promise frequent updates on the ONI website.

No set of Internet censorship measures is perfect. It is often easy to find the same information on uncensored URLs, and relatively easy to get around the filtering mechanisms and to view prohibited web pages if you know what you're doing. But most people don't have the computer skills to bypass controls, and in a country where doing so is punishable by jail -- or worse -- few take the risk. So even porous and ineffective attempts at censorship can become very effective socially and politically.

In 1996, Barlow said: "You are trying to ward off the virus of liberty by erecting guard posts at the frontiers of cyberspace. These may keep out the contagion for some time, but they will not work in a world that will soon be blanketed in bit-bearing media."

Brave words, but premature. Certainly, there is much more information available to many more people today than there was in 1996. But the Internet is made up of physical computers and connections that exist within national boundaries. Today's Internet still has borders and, increasingly, countries want to control what passes through them. In documenting this control, the ONI has performed an invaluable service.

This was originally published in Nature.

1. Understand that you have been caught.

Spitzer quickly understood that the cards where stacked against him and decided denials and platitudes where not going to work for him. Perhaps as a former prosecutor he knew how strong the case was against him. If you are dealing with an incident it is important to understand that excuses for poor security are not helpful right now and dealing with the task at hand has to take top priority. Also do not try to deflect by making up stories of honeypots, false alarms, or “really it is not a problem” statements.

2. Get out in front.

Maybe it is just because I am on the west coast, but it seemed like as soon as I heard the story I also heard that he had a press conference. This is a pretty quick response. In this case he probably knew it was coming since The New York Times probably gave him a courtesy call. You are not going to be that lucky so you will be playing catch up but it is important to respond quickly and decisively.

3. Don’t give up the ghost.

Spitzer’s first press conference was masterful. He admitted everything and nothing at the same time. This is when a good PR person can prove invaluable to the Incident Response Team. You want to acknowledge the problem, give concert steps you are taking, and buy time to get all your ducks in a row. If you are dealing with a large leak of credit cards for example you are going to need some time to figure out just what the heck is going on, who is effected, and what your response is going to be all while waiting for law enforcement to get out of the way.

4. Use the time you just bought.

Assuming you did #3 reasonably well you now have some time to figure out how you are going to respond. If you have law enforcement involved your hands are probably somewhat ties as they are going to want to control the flow of information. One area law enforcement is not going to get involved with is how you are going to respond to your customers. This template seems to have already been written, credit monitoring for a year and some gift cards. You can do better!

5. Cut your loses.

At some point you are going to need to get back to work and put this incident behind you. If the police are not involved this should probably be sooner rather than later. I have seen companies sink a lot of time and effort into trying to catch the person when there is little chance of getting anything out of it. I worked several cases where I tracked the attacker back to some non-US country that is practically impossible to get anything done and especially if it is just you and not the feds. There is some joy in finding out who did it but your time and money      is generally better spent finding out how it happened and correcting the the issue then finding out who. The who is most times irrelevant (unless it is an insider of course).

Post from: Grumpy Security Guy

5 Lessons on Public Disclosure From Elliot Spitzer

In reality, we are a much more secure nation if we do issue driver's licenses and/or state IDs to every resident who applies, regardless of immigration status. Issuing them doesn't make us any less secure, and refusing puts us at risk.

The state driver's license databases are the only comprehensive databases of U.S. residents. They're more complete, and contain more information - including photographs and, in some cases, fingerprints - than the IRS database, the Social Security database, or state birth certificate databases. As such, they are an invaluable police tool - for investigating crimes, tracking down suspects, and proving guilt.

Removing the 8 million-15 million illegal immigrants from these databases would only make law enforcement harder. Of course, the unlicensed won't pack up and leave. They will drive without licenses, increasing insurance premiums for everyone. They will use fake IDs, buy real IDs from crooked DMV employees - as several of the 9/11 terrorists did - forge "breeder documents" to get real IDs (another 9/11 terrorist trick), or resort to identity theft. These millions of people will continue to live and work in this country, invisible to any government database and therefore the police.

Assuming that denying licenses to illegals will make them leave is head-in-the-sand thinking.

Of course, even an attempt to deny licenses to illegal immigrants puts DMV clerks in the impossible position of verifying immigration status. This is expensive and time-consuming; furthermore, it won't work. The law is complicated, and it can take hours to verify someone's status only to get it wrong. Paperwork can be easy to forge, far easier than driver's licenses, meaning many illegal immigrants will get these licenses that now "prove" immigrant status.

Even more legal immigrants will be mistakenly denied licenses, resulting in lawsuits and additional government expense.

Some states have considered a tiered license system, one that explicitly lists immigration status on the licenses. Of course, this won't work either. Illegal immigrants are far more likely to take their chances being caught than admit their immigration status to the DMV.

We are all safer if everyone in society trusts and respects law enforcement. A society where illegal immigrants are afraid to talk to police because of fear of deportation is a society where fewer people come forward to report crimes, aid police investigations, and testify as witnesses.

And finally, denying driver's licenses to illegal immigrants will not protect us from terrorism. Contrary to popular belief, a driver's license is not required to board a plane. You can use any government-issued photo ID, including a foreign passport. And if you're willing to undergo secondary screening, you can board a plane without an ID at all. This is probably how anybody on the "no fly" list gets around these days.

A 2003 American Association of Motor Vehicle Administrators report concludes: "Digital images from driver's licenses have significantly aided law enforcement agencies charged with homeland security. The 19 (9/11) terrorists obtained driver licenses from several states, and federal authorities relied heavily on these images for the identification of the individuals responsible."

Whether it's the DHS trying to protect the nation from terrorism, or local, state and national law enforcement trying to protect the nation from crime, we are all safer if we encourage every adult in America to get a driver's license.

This op ed originally appeared in the Detroit Free Press.

Craig has been instrumental in making FlexWiki what it is today. He's donated a lot of time and effort to the project (I know this, because many of the features he added were ones that I requested). Now that he's leaving the project, hopefully he'll have more time to spend with his family. We're certainly doing our best to keep him busy here at Pluralsight, where his insight and experience is invaluable.

It has been something like four years that I’ve been working on FlexWiki. Not very quickly at times, but I do at least try to put in around an hour every day. For quite a while now, that hour has become more a chore than something I look forward to. But I was committed to completing the tasks I said I would take on, so I kept going.

Well, now I’m done. I even checked in my experimental output caching code, although it's not in the 2.0 release.