A Holistic Approach to Security in Product Development
Our company's entire product line is becoming increasingly IP based. This means that our systems are more interconnected with the customer’s IT environment than they were before. Customers are well aware of the security risks to their networks and systems. So we have to respond aggressively to ensure that our products fit well within a variety of secure environments.
I'm working on a Product IT Security Program designed to respond to a number of challenges.
First, no product and no network is 100% secure. This is why modern security practices not only focus on the security features of a given device or network, but also on the change management and processes that will ensure continued security as new threats emerge.
Second, the environments into which our IP products are being deployed are an increasingly complex ecosystem of third party products, a variety of network topologies and many software integrations. These factors create difficulties for security that require we do our part to ensure that our devices are secure, and that the fit within the customer’s security expectations.
So my goal is to proactively define security objectives for our products. This allows us to design and build products that meet these objectives--leaving nothing to chance. We seek to assure customers and our sales partners that our products are secure and work with them to accommodate their needs in special environments and circumstances that require additional high security.
My approach has been to survey the IT security landscape and collect the best practices from a number of well-defined standards. I'm confident that these security techniques will fit within most all customer compliance requirements, from HIPAA to Sarbanes-Oxley, to various international, government and Department of Defense requirements.
There exists a number of standards that provide detailed security vulnerabilities to be mitigated against. These include vulnerability lists from groups such as Open Web Application Security Project (OWASP), MITRE Corporation, SANS (SysAdin, Audit, Network, Security) Institute, as well as the vulnerabilities built into network and security scanners such as Tenable Network Security’s Nessus scanner.
This vulnerability knowledge will allow us to execute the development practices to design security into our products.
Of course, shipping the most secure systems do no good if new vulnerabilities are found after deployment. To mitigate against this ensure that the user can keep their systems up-to-date for new security threats. And factor in the need for the customer to include anti virus software on deployed systems. This allows the customer to utilize their own best practices for maintaining a secure environment into which the products seamlessly fit.
In advance of security accreditation that the customer may require of their deployed IT systems, I'm focused on the Payment Card Industry - Data Security Standard (PCI-DSS) as a framework to target. While our products rarely directly manage customer financial or credit card information, these products are widely deployed in Point of Sale environments and throughout financial institutions. The PCI-DSS frameworks allows us to be one step ahead in the accreditation process so our products will integrate well within this most secure environment. From PCI-DSS, accreditation in other environments should not be a problem for our customers.
The point is to "put a stake in the ground" with a holistic approach to product security that will provide a starting point to discussions with customers with high security requirements, and will provide proactive answers to assuage customer concerns.
I'm working on a Product IT Security Program designed to respond to a number of challenges.
First, no product and no network is 100% secure. This is why modern security practices not only focus on the security features of a given device or network, but also on the change management and processes that will ensure continued security as new threats emerge.
Second, the environments into which our IP products are being deployed are an increasingly complex ecosystem of third party products, a variety of network topologies and many software integrations. These factors create difficulties for security that require we do our part to ensure that our devices are secure, and that the fit within the customer’s security expectations.
So my goal is to proactively define security objectives for our products. This allows us to design and build products that meet these objectives--leaving nothing to chance. We seek to assure customers and our sales partners that our products are secure and work with them to accommodate their needs in special environments and circumstances that require additional high security.
My approach has been to survey the IT security landscape and collect the best practices from a number of well-defined standards. I'm confident that these security techniques will fit within most all customer compliance requirements, from HIPAA to Sarbanes-Oxley, to various international, government and Department of Defense requirements.
There exists a number of standards that provide detailed security vulnerabilities to be mitigated against. These include vulnerability lists from groups such as Open Web Application Security Project (OWASP), MITRE Corporation, SANS (SysAdin, Audit, Network, Security) Institute, as well as the vulnerabilities built into network and security scanners such as Tenable Network Security’s Nessus scanner.
This vulnerability knowledge will allow us to execute the development practices to design security into our products.
- Begin with a clear process for handling source code and software artifacts within the development organization
- Start with reviews early in product development to assure that the fundamental design of the system will not violate security best practices
- Do code reviews of software during development with explicit tests of security vulnerabilities
- Analyze threat models within the context of a decomposition of the system’s architecture.
- Run security checks as part of our quality criteria during product testing to ensure that no known vulnerabilities are slipping through the cracks.
Of course, shipping the most secure systems do no good if new vulnerabilities are found after deployment. To mitigate against this ensure that the user can keep their systems up-to-date for new security threats. And factor in the need for the customer to include anti virus software on deployed systems. This allows the customer to utilize their own best practices for maintaining a secure environment into which the products seamlessly fit.
In advance of security accreditation that the customer may require of their deployed IT systems, I'm focused on the Payment Card Industry - Data Security Standard (PCI-DSS) as a framework to target. While our products rarely directly manage customer financial or credit card information, these products are widely deployed in Point of Sale environments and throughout financial institutions. The PCI-DSS frameworks allows us to be one step ahead in the accreditation process so our products will integrate well within this most secure environment. From PCI-DSS, accreditation in other environments should not be a problem for our customers.
The point is to "put a stake in the ground" with a holistic approach to product security that will provide a starting point to discussions with customers with high security requirements, and will provide proactive answers to assuage customer concerns.
posted by Steve at 6:57 AM
2 Comments:
Good post, I've been thinking about security in the last few months and this fits well. A couple of thoughts:
* Security is about risk management and mitigation. You have to pick your battles, and the ones you don't pick you have to be willing to lose. For example, do you want a system that can survive the hardware failure of a node? OK, we'll do redundancy. What about not a failure, but an node that is actively trying to screw things up (maybe compromised by a Bad Person)? Then you need Byzantine redundancy and you're going to spend a lot of time passing around voting packets on what nodes think what other nodes are sane. That might be a battle you're willing to lose.
* The easiest way to break most systems is through social engineering. Schneier has a recent post that is sort of relevant (http://www.schneier.com/blog/archives/2009/01/impersonation.html) and there is Mitnick's whole "social engineering". Amazingly low tech ways of defeating security.
* Finally, back in grad school days we had three letter companies and three letter gov't agencies interested because we were doing formal specifications of safety critical security properties. The key to this is you have to do it at the right level of abstraction, and then be careful with the refinements toward implementation. For example, it seems silly but one thing we looked at was a security officer's workstation. The most obvious property is that you can't let users view information at a higher security level (there is also need-to-know, but that complicates things :) But when you start playing around with such things you also realize that you can't let users create information at lower security levels (since they might do that to, say, leak secret information to an object that an unclassified user could then read). Not immediately obvious to most people. Anyway, those properties are easily stated using formal-ish specification notation and then tracked. Similar approaches can be taken to voting machines. My point is that by doing careful work up front with making the security properties explicit, you can make sure they carry all the way to code.
Speaking of code, I am still thinking about it. One thing I've mulled over is whether going to a design-by-contract (Bertrand Meyer) or a cleanroom approach (Harlan Mills and "intended functions" that are checked at code review) make sense. The latter is also attractive since it takes a minimalist approach to the language constructs available to programmers, with the hope that the resulting code is easier to verify.
Part 2: It was late last night and I forgot to give an example of even when you get things right. With the multilevel secure security officer's workstation, you can enforce the read-down & write-up critical requirement, but it was still possible to use a covert channel to leak information by manipulating system/network objects or performance(see the Additional Reading on this page: http://en.wikipedia.org/wiki/Covert_channel
Post a Comment
<< Home