Abstract: Creating a Security Verified Standard for Hardware and Software Many new software and hardware claim that they are secure, but there currently is no standard to determine the measurement of it’s security and it does not specify at what layer of the OSI model it is secure. A standard of measurement is needed in the industry to allow consumers the ability to determine quickly if the software and hardware functionality they wish to implement has the ability to be secure within their network. Security means different things to different people. A Vice President or manager may think that their network is secure simply because they had purchased the necessary firewalls. The TJMax breach where hundreds of thousands of customer credit card information was stolen, is a great example of how a firewall does not protect against intrusions or software vulnerabilities. To the systems administrators, they may see part of the real story. They see this same network as insecure, subject to intrusions that may go undetected. Developers may see the other part, software in this network subject to Cross-site scripting, while database administrators see it subject to SQL injection. Each technical member, in the organization, working in the different parts of this enterprise should be concerned that the piece of hardware or software they are installing in their part of the architecture is secure. At the present time consumers usually buy software and hardware (with the exception of security pieces) because of their functionality rather than their security features. In most cases, securing the architecture is done in the second round of architecture. Because security decisions need to be made easier, more cheaply for consumers, there is a need for a security verification standard. These standards would outline how the software and hardware would be considered secure. Each level according to the OSI model would contain it’s own set of standards. Once the software/ hardware passes the verification a label can appear nest to the software. This will make decisions easier for consumers and essentially easier for upper management to understand. Different software runs at different levels of the OSI model. Each portion of a network has different vulnerabilities and different security risks and threats. This means that each level must be secured in its own way. For example, a firewall may only protect the network from different ports, but will not protect the application within the dmz from cross-site scripting. However if the Oracle database came with written instructions on how to prevent against SQL injection, then database administrator would be more aware of these issues. Most software must be configured in order to make it secure. Instructions and documentation may need to be given along with the users manual for the new software/hardware on how to lock make it secure. For example, a Linux may come with directions on how to harden the OS. As part of the security standard, the written instructions may contain recommendations on root access, available ports, and other known ways to harden against exploits of the system. Containing these instructions is an example of the type of the security standards needed for hardware to be considered secure. |
Workshops > cs-ga-2010 >