Advanced Security Testing: Moving to Standardized Security Testing

We have been talking about routine vectors that can be exploited to access any system, including IBM via the IFS. Importantly, as environments have become more multifaceted other areas of the business may have vulnerability. Protecting the organization requires we have a testing approach that accounts for all the factors that can breach our security. In the next set of articles, we are going to look at advanced security tests and how to organize them.

It is important to always begin with assessing what we care about and why, and how we are doing things today as well as what we have identified as existing procedures.

 

Testing is all about mitigating risks, since we can never eliminate everything entirely, and identifying the same to the stakeholders so relevant decisions can be made. Building on the general risk management covered earlier we move into security risk assessments. Start with what is important to the business, the mission, function, image, and reputation. An ironic fact of QA is some of the issues that have the least impact on the actual business and customers are the most embarrassing and ones that no one ever sees are the most damaging. We want to know what can hurt our assets, individuals, other entities, etc.

 

Next, we need to link these areas to loss of confidentiality, integrity, information, or system access.

 

Organizing the above would involve a matrix combining risk on a scale of impact and the importance of the artifact. From there we move into existing security policies and procedures. Knowing what we believe we are protecting and preventing, and proving that correct is tremendously important for a baseline.  The business needs to define things such as acceptable use, minimum access, network access, remote access, internet access, managing users, data protection and classifications, configuration and change management, server security, mobile, guests, physical security, and user practices (don’t put passwords under your keyboard), passwords policy (long beats difficult and changing often isn’t proven to make an appreciable difference), malware protection, incidents, auditing, software licensing (out of date software is a known danger), electronic monitoring and privacy, security procedures. The list seems daunting, however, if we look at that last sentence as a way to organize our efforts the overall test plan starts to look like an elephant we can eat, albeit one bite at a time.

Next entry portion is the auditing component.

 

We see over and over that security remediate tends to be in response to an audit. While oversight itself doesn’t make us secure, it does make us accountable. Also, important to note, there are instances where apparently insecure practices are the right ones for us to have in place. They just need to be documented and tracked so they aren’t exploited. Whether responding to an audit or performing an internal review there are areas for us to focus on. Assessment, prevention, detection, reaction, and recovery all need to be accounted for. Equally important as covering these areas is understanding the purpose of the audit and what the organization needs to do with the information. Addressing concerns such as physical security, password maintenance and standards, user rights and sharing authority, server-level security and maintenance, vendor risk, intrusion, and response plan creation are all logical responses to auditing recommendations. After an audit or review risk identification and mitigation needs to be determined for the next steps and to identify threats before they become problems.

The above is the very tip of the security testing ice burg. Next month we will talk about purposes, goals, and strategies.

 

 

More from this month:

Leave a Comment

Your email address will not be published. Required fields are marked *