As in so many other areas of testing in general as we get deeper into the process of security testing, we focus on specific areas. Definition, planning, design, execution, evaluation, and maintenance are the natural next steps as security testing is implemented strategically.
First, we need to define what we need to do in order to determine how to do it.
This is also a lifecycle activity. Implementation of practices and proper validation of them are needed throughout the project. This is an area where alignment between development types and testing objectives is crucial. The organization’s testing risks and needs will be unique to the nature of the company, the software development process, and the business risks. Then we align the testing process to the particular lifecycle model accounting differently for sequential, iterative, commercial off the shelf (aka 3rd party) and open source.
Security test planning needs to focus on 2 aspects; verify the designed security defenses are implemented and function, as designed and verifying no vulnerable, are introduced.
We need to identify who should perform the testing. What is the schedule and is the information being used to determine it realistic. What tasks are involved and how long will they take. What environment will this be testing in and does it mimic production closely enough to be accurate. Lastly what authorizations are needed.
Design phase has different ways to be approached. Risk analysis, threat model, or ad hoc origin categorization of risks are all valid basis and depending on the type of project of these may be needed. Attributes needed are prioritized by risk and threat models, traced to requirements, known intended audience, define known security defect profiles, and automation.
The execution needs to closely analyze the environment more than in other areas of testing.
Isolated from other environments and the malware risk is crucial. Completeness includes systems and applications under test, operating systems, networking, middleware, client/server configuration, mobile concerns, databases, access rights, browsers and plug-ins, co-existing applications, data. Planning and approval is also heightened in this area. Compliance and regulatory laws plus the business risk of an improperly identified intrusion attempt can be devastating.
Evaluation reports need to be as detailed as possible and this is an area reporting cannot be overlooked. All of this feeds into the maintenance of these tests. Given all the work involved they need to be reused and to evolve with the software development lifecycle of the applications.
Next month we will take a deeper look into these concepts.
More from this month:
- Groundhog Day for Malware
- iAdmin Fall 2021
- IBM i Security Resource Page
- iTech iTip Videos
- Sips & Tricks: Coffee with iTech
- iBasics: IBM i Education for the Beginner System Administrator
- iPOWER Hour Podcast Episode 33: Assessing Your IBM i Cybersecurity Risks
- Upcoming Events
- iTech Spotlight
- IBM i, FSP, and HMC release levels and PTFs (October 2021)