The CodeGuard Blog

In words that may go down in history, on July 6, 2009, U.S. District Court Judge Richard Jones wrote: “In order for ‘personally identifiable information’ to be personally identifiable, it must identify a person. But an IP address identifies a computer,” An overview of the ruling is here.

This ruling dismissed a case by certain people against Microsoft, claiming that Microsoft’s recording of their IP addresses constituted a violation of Microsoft’s End User License Agreement or EULA.  The plaintiffs claimed that a user’s IP is personally identifiable.  Microsoft, claimed otherwise.  In this case, the judge agreed that an IP is not PII.  That’s a good thing for all of us in the security business, but it’s also the right logical conclusion at this time in history.  Here’s why.

1. IP addresses are assigned by ISPs.  They are not assigned by end users.  Most computers only obtain a lease on an IP address for days or hours.  As such, the IP address is often just a temporary association between a computer and the Internet.  It’s not the same as the relationship between a user and the user’s computer.
2. You can’t buy an IP address, you can only lease one.  In this regard, it is not “property” as would be defined in many legal circles.
3. IP addresses are easily computed and many attack programs generate IP addresses randomly and attempt to connect to those addresses.  If you look up a specific IP address via reverse DNS, you can associate it with a domain, but users can also mask their personal information in the domain record – if they work through an ISP or other representative.  If IP addresses are considered PII, it will destroy the long term viability of DNS.
4. Finally, the Internet is not a government owned or regulated entity, as are the phone companies in many parts of the world.  Although certain governments may choose to limit use of the Internet as a matter of national policy, those regulations would not and should not apply across national borders.  In short, they can’t tell the Internet what to do.  The Internet is flat and those who would unflatten it are swimming upstream. Just ask people who want to tax Internet sales.

There are other issues, but I think you get the idea. 

Of course, this means that I think the EU made a mistake when they required ISPs to restrict access to IP information.  It is harming the competitiveness of IT companies over there.  If you disagree, let me know why.  I’m interested in your opinion.

Jim Molini, CISSP, CSSLP

One of the projects I’ve been working on recently is to prepare a reading list for software security professionals.  Over the years it has become increasingly difficult to find the right reference papers on topics that should be of interest to all of us.  The hardest paper to find is the paper that described the original Clark – Wilson integrity model.  However, after 5 years of searching, I found it and uploaded it to the Papers directory here on the site.  You can download here from this site.

I tracked down the Clark-Wilson paper precisely because it was so difficult to find.  It was presented in 1987, the year before the IEEE began storing Security & Privacy conference proceedings online.  Therefore, it was relatively easy to find Brewer Nash (published in 1988), but almost impossible to find Clark Wilson.  Even the references to the paper are missing data that you can only find in their original text.  Other integrity models are available through other channels, but I had never seen a source on the Internet for this specific document.  So I finally found a copy at Stony Brook University in New York and uploaded it as a service to the community. 

Why?

I think that this model is important for a few reasons.  First, Clark-Wilson is one of the early models that successfully described a workable approach to data integrity.  I was not impressed with Bibabecause it appeared to merely rehash Bell-LaPadula, replacing disclosure with integrity.  I did not see in Biba the specialized attention that integrity controls required.  Brewer-Nash (aka “Chinese Wall”) was a good paper, but still relied on users to control their own actions.  Clark-Wilson, however, seems to work without special “struts.”  It is also most compatible with modern object oriented systems, IMO. 

In a well formed OO system, data transformation is bound to the entity that hosts the data.  This is compatible with the concept of the Transformation Procedure.  Moreover, the concept of a Constrained Data Item can be implemented through a variety of object interface management methods, like getters and setters.  So Clark-Wilson gets my vote for best integrity model from the early offerings.  There have been improvements.  I’ll talk about them in a future post.

Until then, look through the model.  Think about how it could improve the quality of your system.  Then post a comment to let me know if you agree or not.  I’d be interested to hear your perspectives. 

Jim Molini, CISSP, CSSLP

File this one under the heading “No Good Security Deed Goes Unpunished.”  This week, the Wall Street Journal reported on a former Vice President at Goldman Sachs who was arrested by the FBI for allegedly stealing source code from his former employer.  You’ll find a detailed description of the circumstances and possible impacts by Tyler Durden on the Zero Hedge web site.

If all the allegations are true, Sergey, who managed a software development group in the program trading business for the Goldman Sachs, apparently decided to steal some of the software that makes it work.  Whether this is Goldman’s “magic sauce” for trading or not, is beside the point right now.  Here’s what I can see from the recent media reports:

Sergey worked for Goldman in their VP of Equity Strategy, according to information uncovered by  Zero Hedge.  According to the affidavit sworn out against him, Sergey downloaded 32 MB of source code from his company, within 5 days of leaving for another firm.  BTW, the other firm was apparently willing to triple his salary for making the move.  About a month later, he was arrested while returning from Europe and charged with stealing the software. 

To a computer security guy, this would say that Goldman Sachs had a program in place to detect and report unauthorized transfers of certain software components.  This is a good thing, right?  Moreover, the response team was good enough to identify a potential theft and run it through channels until an arrest warrant had been prepared and served by the FBI.  All of this happened in less than a month.  That’s great security work.  How many other firms would have been able to find and track this kind of event at all?

Unfortunately, other reports have focused on many of the possible negatives for Goldman.  That’s too bad.   This was a classic bit of investigative and response work at a major financial institution and it may have prevented important software from falling into the wrong hands.  If nothing else, it has sent a great message to everyone who develops software at the firm.  The message is, “We will protect your intellectual investment in our success.”  My advice is to gut it out while the world gets used to a company who will protect all assets.  So my hat’s off to Goldman Sachs.  Hopefully, after all the legal wrangling is over, they can tell us how they did it.

 Jim Molini, CISSP, CSSLP

If you develop software under contract to another organization, you will probably find that you must create a security development lifecycle (SDL) that is different than the in-house model I discussed last week.  Security under contract includes custom software development work done by local, as well as offshore software development houses for customers.  This is how we developed software for the US Space Program and how many large organizations develop or maintain their critical applications.  Developing software for someone else means that you must meet their standards, regardless of your own expectations.  If you fail to meet their minimum standards, you may open yourself to legal liability.  If you exceed their expectations, you may find that you are underbid by another development shop for future work.  How do you reach the right balance?

First you must understand the client’s perspective on software security.  Are they risk tolerant or risk averse?  Do they know enough to be concerned about the possible vulnerabilities in the application you are developing?  Clients often tip their hands about risk tolerance in their initial request for proposal (RFP).  Read the entire RFP and look for broad statements about security.  Even if the requirements section is thin, you may find that the policy section mandates more security than the specification does.  If you see this, you know that you will have to ask additional questions.  This is also a good time to educate your client on the specifics of software development security.  Explain the risk of poor application security and the cost of building security in.

You will demonstrate the added value of your SDL in your proposal.  If you’re already under contract, talk about it anyway.  Be sure to show how you can improve the security of your work at a reasonable cost.  If you can’t be accurate in your cost estimation process, your SDL and your project will fail.  It’s that simple.  Your SDL should be efficient and based on a known standard.  Clients like it when contractors adhere to independent standards so you should be able to favorably compare your operations to those of other well-known organizations.  In that regard, your CSSLP certification should help you to establish your own credibility.

Doing security under contract means that you will spend more time tuning security requirements.  Get this right or you will pay for it later.  I still remember a government contractor who delivered an unusable application and then blamed it on the customer, saying, “You didn’t provide us with any performance requirements.”  In my opinion, this type of behavior borders on professional negligence.  If you fail to ask about security requirements and fail to provide feedback on the impacts of those requirements, you should not expect much repeat business.  If, however, you ask about security requirements, explain the risk and are told that your client cannot afford the kind of security you offer, define a set that is affordable until both sides understand both the risk and the cost.

Once you have estimated the cost of security, it’s your job to make sure that you can effectively deliver the level of control that your client has specified.  Good security design makes all the difference here.  Security under contract means that you should optimize your security mechanisms to the client’s environment.  Build to their authentication system.  Report in a way that is compatible with their auditing standard.  Work with their access control system where possible.  If you build your software for multiple clients, abstract these interfaces into an API.  Doing these things will dramatically improve the psychological acceptability of your system and is often something that they are willing to pay for.

You should build your security mechanisms with the expectation that they will be used and tested by a third party.  This is a common feature of many government software projects and you have to be ready for it.  It’s harder because a third party may not use the software as you intended it.  This will add time to the delivery phase of your application.

Finally, consider security during the system maintenance cycle.  Document your security features well and show how the security of the application can be upgraded to stay compatible with evolving technology.  If you do things right, you may find yourself under contract for 10 or 15 years.  This is not unusual for large contract jobs.  However, if you do security poorly, you may find yourself replaced because you don’t have the necessary differentiators to be considered a long-term partner.

The other major delivery model addresses security for Independent Software Vendors (ISVs).  ISVs require the most sophisticated and diverse model for an SDL.  It’s impossible to address that model in a blog, so I’ll move onto other topics unless I hear of interest from you, the readers.

Jim Molini, CISSP, CSSLP