Plan Rules and Security Testing

Plan rules and Security testing Plan rules for security designing • Plan rules embody great practice in secure frameworks design. • Plan rules serve two purposes: • o They bring awareness to security issues in a programming group. o They can be used as the basis for a review checklist that is applied during the system approval process. Plan rules here are relevant during software specification and design. Plan rules 1-3 • Base decisions on an explicit security policy o • Avoid a weak link o • Define a security policy for the organization that outlines the central security requirements that should apply to all organizational systems. Ensure that a security failure can result when there is more than one failure in security techniques. For example, have password and questionbased authentication. Fail safely o When systems fail, for any reason, ensure that sensitive data cannot be accessed by unauthorized users even though normal security mechanisms are unavailable. Plan rules 4-6 • Balance security and ease of use o • Log user activities o • Try to avoid security measures that make the system difficult to use. Sometimes, you need to accept weaker security to make the system more usable. Keep a log of user activities that can be analyzed to find out who did what. If users are aware of such a log, they are less likely to act irresponsibly. Use overt redundancy and variety to reduce risk 1 Plan rules 7-10 • Indicate the arrangement of all system inputs o • Compartmentalize your resources o • Organize the system so that resources are in separate areas, and users only have access to the data they need instead of all system data. Plan for deployment o • If data formats are known, you can ensure that all inputs are close enough so unexpected inputs don't cause issues. Design the system to avoid deployment issues. Plan for recoverability o Design the system to enhance recoverability after a successful attack. Parts of secure systems software • • Vulnerabilities are often language-specific. o For example, array bounds checking is automatic in languages like Java, so this isn’t a vulnerability that can be exploited in Java programs. o However, many programs are written in C and C++ as these allow the development of more efficient programs, so simply avoiding the use of these languages is not a sensible choice. Security vulnerabilities are closely related to program reliability. Security testing • Issues with security testing: o Security requirements are 'won't' requirements, meaning they indicate what shouldn't happen. It isn’t usually possible to define security requirements as simple requirements that can be directly checked by the system. o Attackers are clever and look for weaknesses. They can test to find flaws and loopholes in the system. Security approval • Experience-based testing o The system is examined and tested against types of attacks that are known to the approval team. 2 • Penetration testing o • Tool-based analysis o • A team is established with the goal of breaking the system’s security by simulating attacks on the system. Various security tools, such as password checkers, are used to analyze the system in operation. Formal check o The system is checked against a formal security specification. Significant points • Security risk management is concerned with assessing potential losses from attacks and determining security requirements to minimize those losses. • To specify security requirements, you should identify the resources to be protected and define how security procedures and technologies should be used to safeguard those resources. • Main considerations when designing a secure system architecture include organizing the system structure to protect key resources and deploying system resources to limit losses from a successful attack. • Security design rules alert system designers to security issues they may not have considered. • Security approval is difficult because security requirements state what shouldn’t happen in a system, rather than what should. Furthermore, system attackers are intelligent and may have more time to test for weaknesses than is available for security testing. 3