Security Testing and Assessing Risk
Thought leaders throughout the software community are taking over the TechWell Hub for a day to introduce themselves, answer questions, and engage in conversations.
Shachar Schiff is the founder and principal consultant at BadTesting, a company that helps organizations manage risks associated with technology changes. He is passionate about nonfunctional requirements, quality assurance, and context-driven testing.
@Shak presided over our most recent Slack takeover, which led to some insightful discussions.
Assessing Code Coverage like a Risk Analyst
“How can we assess code coverage for security testing?” —@Helen Beal
“From a security testing point of view, the best way to assess code coverage is from a risk analyst perspective,” Schiff said.
From a risk perspective, it’s good to focus on the pieces of code or applications that have the greatest risk.From an automation point of view, such as scanning software, that's just as important as penetration testing and manual testing, but a different strategy, Schiff said.
“And with all security testing, we obviously have to be aware of the risks.”
Non-Security Risk Assessments
“We talk about risk assessments in the context of security all the time. What about run-of-the-mill, non-security, regular QA testing? What role do risk assessments play there?” —@Gene Gotimer
Schiff said risk assessments are critical for QA testing and, he believes, essential to good product development.
“For non-security risk assessment and the roles risk assessment plays, this is broadly applicable on most software and apps,” he said. “For UX and UI, any poor experience from the user perspective would be bad. But a risk assessment is central to a good user experience by identifying what not to do, and hopefully building an app that has the best user experience possible.”
Starting a New Job
“Hey Shak, as a regular employee, it seems like it takes me a few months to get up to speed with a new employer. As a consultant, you’re regularly changing environments. What are some tips for quickly ramping up and delivering value in a new job?” —@Josh Gibbs
Schiff said this can be separated into two buckets: a new job with a new client, and a new job with a returning or ongoing client.
For a new client, he advised “to always be as transparent (of course) as possible, and remind them that there is ramp-up time. A great way of passively reminding them is being transparent and asking questions,” which is part of the learning and exploring process.
He also recommends finding out what is important to them for strategy and prioritization. Budget is important to know, as that will dictate the testing strategy: What's the best use of my time based on budget and deadlines?
For a returning or ongoing client, Schiff said that if it’s an entirely new team, then they could be treated the same as with a new client. But if it is a team you’ve worked with before, “sometimes they tend to ask for more or give shorter deadlines,” he said. If they have a demanding schedule, he recommended reminding them that testing takes time.
Schiff said his biggest takeaway from this takeover was how testing is not “one size fits all.” It comes with challenges regardless of the software size, complexity, or team.