[SCADASEC] SAFECode on software assurance
BlackSwanSecurity
BlackSwanSecurity at gmail.com
Fri Feb 15 05:37:09 CST 2008
This is great if you are EMC, Juniper Networks, Microsoft, SAP or Symantec.
The question is: when, and to what extent, will the developer of the third
party software component embedded in an industrial automation or control
system which is in turn developed and supported by a control systems vendor,
deploy such best practices?
Sure, the big boys will lead the way, but it takes a long time for the
little guys to catch up (and that's assuming we even know who the little
guys are and where their software is embedded).
On 14/02/2008, Bob Radvanovsky <rsradvan at unixworks.net> wrote:
>
> URL: http://www.gcn.com/online/vol1_no1/45811-1.html
>
> SAFECode on software assurance
> Software Association Forum for Excellence in Code outlines core practices
> for secure software development
> By William Jackson
>
> An information technology industry group formed to develop and share best
> practices for secure software development has released its first paper,
> outlining the core practices being used by member companies.
>
> The Software Association Forum for Excellence in Code (SAFECode) was
> announced in October as a way to enhance communications between software
> companies. Many companies have internal programs to improve the quality of
> the code they are producing, but a lack of communications has limited their
> effectiveness, said former White House cybersecurity adviser Paul Kurtz,
> executive director of SAFECode.
>
> The paper, titled "Software Assurance: An Overview of Current Industry
> Best Practices," is the group's first product.
>
> "As the initial step in our efforts, SAFECode has identified the assurance
> best practices that have proven to be effective across its member
> companies," Kurtz said.
>
> Founding members of SAFECode are EMC, Juniper Networks, Microsoft, SAP and
> Symantec.
>
> The group acknowledged the difficulty of prescribing security processes
> across the technology industry. "Not surprisingly, there is no single method
> for driving security and integrity into and across the globally distributed
> processes that yield technology products and services," the report said.
> "Yet, regardless of the method used, there is a core set of best practices
> for software assurance and security that apply to diverse development
> environments."
>
> "By sharing this information, we hope to encourage the adoption of these
> types of practices by other software developers and respond to the growing
> customer desire for greater visibility into the steps technology vendors are
> taking to continually improve the security of their products," Kurtz said.
>
> The paper identifies and explains security best practices and controls
> currently used by SAFECode members:
>
> * Security training: A prerequisite to coding secure software is for
> engineers to be knowledgeable about information security issues affecting
> users.
> * Defining security requirements: Requirements must be defined in the
> early stages of product development.
> * Secure design: The early design phase must identify and address
> potential threats to the application and ways to reduce those risks.
> * Secure coding: The product development team must implement secure
> programming practices.
> * Secure source code handling: The integrity and confidentiality of
> source code must be protected.
> * Security testing: Specialized validation should be implemented to
> ensure that security requirements, secure design and coding guidelines are
> followed.
> * Security documentation: Documentation for users should help customers
> understand how to optimally configure security controls, and how
> configuration options could produce potential security vulnerabilities.
> * Security readiness: Prior to releasing a product, the application
> developer must evaluate, document and assess risks posed by potential
> security gaps in the product.
> * Security response: An incident response mechanism must be in place to
> relay reports of security vulnerabilities (exploited or not) after the
> product is released to the product development or sustaining teams for
> mitigation.
> * Integrity verification: Products must offer customers methods to
> verify that the software they have acquired is from their trusted vendor.
> * Security research: Ongoing research should be conducted into new
> threat vectors and ways to mitigate them.
> * Security evangelism: Leaders in the area of software assurance should
> promote the use of best practices by discussing their practices and findings
> in open forums, articles, papers and books.
>
> "Vendors who have implemented these best practices have seen dramatic
> improvements in software product assurance and security," Kurtz said.
>
> Beyond development by the vendor, the paper also outlines the
> responsibilities of integrators, who must work with vendors to mitigate
> vulnerabilities that could be introduced when an application is integrated
> into a heterogeneous environment; operators, who must ensure that systems
> remain properly configured and patched and protect them from intrusion; and
> end users, who should report bugs and not introduce untrusted software into
> systems.
>
> _______________________________________________
> To unsubscribe from this mailing list, please visit:
> http://news.infracritical.com/mailman/listinfo/scadasec
>
> To review our privacy statement, please visit:
> http://www.infracritical.com/privacy.html
>
> scadasec at news.infracritical.com
> http://news.infracritical.com/mailman/listinfo/scadasec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://news.infracritical.com/pipermail/scadasec/attachments/20080215/ecdfa59c/attachment.html
More information about the scadasec
mailing list