Have you changed the password of your heating system so that your neighbors cannot stop the heat? Does your baby phone carry a virus that supports botnet attacks? Has your car been opened by a thief’s mobile phone? The doors of IoT devices seem to be wide open!

Do you want to be responsible for the test of the application that made it into the news that way? Is there an excuse that security had not been considered enough?

Obviously not. But I am sure, the teams developing the above software also did not intentionally leave the doors open. So, what can we do?

The Learning Process

Between two projects I got the chance to tackle the theory about application security. I wanted to find out if an average test manager is able to get the concepts so that she can use it to the best for a given project. Maybe to avoid the above. Maybe there is no excuse.

First, I looked for a classroom training class but did not find any. Then I started finding self-training material:

There are so many resources! To find out where to start, I checked with some colleagues who are professionals in enterprise security, and they also gave me some intro – which I did not really understand. Yet. The more people I asked, the more different answers I got. Again, like in the story with that elephant in the room where everybody touched a different part I was not able to create a picture from all of that.

My rescue was a class about information security by Dr. Humayun Zafar of the University System of Georgia hosted by Coursera. The main strength of that class was that it pulled together a lot of reading material from many different sources about information security in general. One could learn about the different layers of an information system and their weaknesses, about regulatory requirements on information security (mainly US), about how to build secure software. That gave me a glimpse of the magnitude of information in the web, sorted in a very meaningful manner.

Starting from here, I was able to categorize a lot of the reading I got from HPE internal sources, and got further material. And as I started understanding the answers I also was able to ask more intelligent questions.

And also, I now was able to search the web in a more efficient way. In the end I found a blog about how to learn security testing, and I guess that really would have been a shortcut for all my efforts: @katharinathetester you can find a great summary about the security testing pathway.

My Findings

There have been a few highlights for me on this process – and I’ll leave explaining the details of application security to those who really understand them…

• After about three weeks of reading and discussing I guess I have enough awareness to ask good questions – but still no idea how to really perform security testing. Good to have guys around who can be consulted….
• Are security requirements just another kind of requirements to be quality assured as early as possible? Yes, they are, AND no, they are not: anything that can be formulated as a requirement should be tested like one – but there is room for more criminal energy…
• Defining relevant security requirements for a project or product is even more difficult than for business requirements as you have to build in resilience for situations your own not so criminal mind was not able to think of.

My personal awareness of the matter increased. I now see all those articles about security breaches – if you really want to become paranoid then google “IoT security breaches”. Or, if you are the visual kind of learner: there are great charts about IoT, password misuse, security breaches on http://www.informationisbeautiful.net/subject/web-tech.

Seeing how enthusiastic not only my company gets about IoT, I think, it is absolutely relevant for everybody to understand the concepts, wording, and high level attack and defense mechanisms for integrity, confidentiality and availability – not to speak of privacy. So, I tried to give a one hour intro to my peer group… I fear leaving them worried. It was followed by a presentation of a life hack and how HPE could have supplied mechanisms to avoid that open door. Practical experience and examples usually help. But for now, it also left us shocked. It was so easy to do cross site scripting and sql injection. But also, it would have been possible to avoid that when using static analysis.

The Software Security Lifecycle

Not only HPE has created many tools to cover the different aspects of avoiding insecure software,  but I think using the tool structure, they give a very good overview of the live cycle of creating secure software. As for any other software development, this needs to be extended by whatever work you do beyond just building: collecting requirements for security functionality (like. “log in using a two step authentication”) or considering regulatory compliance for the market of interest. On top, there are also many best practices for architecting a secure software solution (like compartmentalization of software).

In order to create and maintain secure software it is relevant to avoid any kind of common pitfalls at time of implementation, to properly test before release and to monitor in production for discovering breaches or attempts of breaches. All relevant information needs to be considered for further build, test, release, deployment and operation.

Another approach to define a Security Development Life Cycle (SDL) has been pursued by Microsoft.

Their additional emphasis is put on a training phase as “a prerequisite for implementing the SDL. Foundational concepts for building better software include secure design, threat modeling, secure coding, security testing, and best practices surrounding privacy need to be spread out to everybody involved.”  I guess that suits my point!

Success?

As a test manager, I now would be ready to ask nasty questions about security testing approach. However, it is even more important that everybody involved into creation of software needs to be aware and to handle the whole thing well. From a more test focused perspective: my main learning is, that there is a need of security testing professionals + a couple of tools to resolve this. Good, professional testing to the extreme. It seems rather easy to raise awareness, but to become knowledgeable it is a long way…