Baking Compliance into the SDLC

The executives at my company "suggested" that we should include the PCI DSS into our enterprise SDLC. My first thought when I heard that suggestion was "no." Not in "no, that is a terrible idea" but "no, I think you are missing the point of statutes such as PCI, HIPPA, etc." The point of compliance is to force the enterprise to maintain a minimum level of security in the areas that the standard or statute are concerned. For example, PCI only cares about credit card information, HIPPA is solely concerned with medical information, SOX financial data, etc. and those statutes only mandate minimum controls around the data of concern. What about the rest of the data? What percentage of data that is traversing the corporate network involve these other data types? What data is important to the business besides financials? What data, if exposed, would put lives in danger? Of course PCI, HIPAA, et. al. protect important information belonging to customers and employees alike. But what about intellectual property? If you are an airline would a flight manifest or crew assignment be of interest to a potential hijacker/terrorist? If you are a shipping company would a cargo manifest of drugs being sent cross-country be of interest to thieves? Obviously, some of the data that is critical to the functionality of the business is also some of the data that can do the most harm if compromised. To get back to the topic at hand let's consider "baking" parts of the PCI DSS into the SDLC. I can write the SDLC that forces PAN masking and encryption. From my experience, the issue that will develop is that anything that is not included in the SDLC will not be masked or protected. For example, if I don't include driver license or social security numbers the developers will assume that they must not be sensitive and will not protect them. So I will have to include them in the SDLC. What about addresses and phone numbers? Frequent-flier accounts? Travel history? How do you protect sensitive operational information? Flight manifests, crew lists, employee rosters, the list goes on and on. What this leads to is policy that is over-developed, confusing, contradictory, and most of all, impossible to enforce. I do understand and agree with the sentiment of getting security involved early and often in software and systems development. Instead of focusing on bare the minimum to avoid lawsuits and prosecutions we should look at developing best practices that will secure all data and systems that reside within the enterprise. Guidelines and policies that force the architects and developers to identify data they will be dealing with and how the business views that data is a good first step to protecting the data by hashing, encrypting, or masking, etc. To aid architects and developers during the initiation portion of the SDLC we as security professionals must make every effort to bring some common sense to securing the proposed application. The fact that many projects make it all the way to testing and/or deployment before security finds out about it is why the industry has been reduced to bolt-on solutions, insecure networks, swiss-cheese firewalls, and vulnerabilities galore. But that is a subject for another post (or 50).