Embedding Security Testing in SDLC

I recently attended the “Certified Ethical Hacker” course to gain an insight into the world of Security Testing.

The CEH or Certified Ethical Hacker is one of the premier certifications from the EC-Council organisation. There are a few certifications out there on Ethical Hacking and Penetration Testing but the CEH is the one that is recognised worldwide. If you are a Security specialist or a Penetration Tester, CEH is one of the premier certifications to have.

 

Why I took the CEH course?

There are essentially three reasons why I decided to take the Ethical Hacker course:

1 – Ever since I became involved in web application testing, I had an interest in how web applications can be attacked and how to prevent those attacks.

2 – Although not a new domain, security testing is fast becoming more prominent. With technologies such as the cloud and IoT, more and more devices are connecting to the internet and so security measures must be taken into account when designing and testing systems/applications.

3 – Upskilling myself in cybersecurity. By taking the course, I realised the areas that I’m lacking and where I need to improve.

I firmly believe that as QAs, we should not be focused only on functional testing anymore. Penetration Testing, like performance testing, should be part of the SDLC and we should be able to test for vulnerabilities and fix them while the application is being developed.

 

Overview of the CEH Course

The Certified Ethical Hacking course teaches and tests your ethical hacking skills. It’s not really a test of how good you are on networking or your security skills, programming ability, or administration skills, however, it does help to have knowledge of all of these things.

You need to know networking fairly well. You also need to have a little bit of programming and definitely some security skills and knowledge as well.

The course is five days long and covers both theory and practical demonstrations of hacking concepts. There are no pre-requisites in taking the course, however, as mentioned before, knowledge of networking and operating systems helps a lot.

At a high-level, the course covers the following topics:

  • Concepts of hacking, steps involved in hacking and types of hackers
  • Various types of attacks including Session Hijacking, Denial of Service and SQL Injection
  • How to identify vulnerabilities
  • How to use various tools to exploit vulnerabilities
  • Social engineering
  • Hacking web applications, web servers, and wireless networks

It should be noted that just by taking the CEH course and/or the exam one does not become a cybersecurity expert. It requires years of experience in this field and a deep understanding of networks and general security and hacking concepts.

How does the course help in delivering more secure software?

 

The Hacker Mindset

As the old saying goes, “To catch a thief, you need to think like a thief”. The same applies to security and hacking. In order to secure a system, we must be aware of various techniques that hackers use to exploit a system.

Hackers have a thirst for knowledge and are always trying to find new exploits and unexpected behaviours from a proven or existing process or system.

Described in a different way, hackers seek to use a system in a way that it was never conceived or designed for, to find out what the outcome might be.

Taking the CEH course provides an insight into the world of security and hacking and what tools and techniques hackers use to look for vulnerabilities and thus exploit systems.

By becoming an ethical hacker, we can then use the same tools and methods to “pentest” a system and report on vulnerabilities, so potential attacks can be prevented.

Security testing should be part of the development process.

 

Embedding Security Testing in SDLC

In the new era of digital transformation, organizations across industries are embracing initiatives around automation, cloud deployments and containerization of applications.

Utilizing the new technologies and the DevOps way of working, we can reduce the time to market of new applications and features.

However, in the race to deliver everything faster, it’s all too common for organizations to quickly realize that they’ve landed in a deepening pool of security debt that hackers are eager to exploit.

When studying recent security breaches [leaked S3 bucketsHackers attack Jenkins Server] it is evident that there is a growing interest in targetting and exploiting DevOps environments, CI/CD tools, and cloud infrastructures.

In the DevOps model, automated unit, integration and acceptance tests are essential quality controls in running a reliable continuous delivery pipeline.  Penetration testing, on the other hand, is usually left out of this process. Penetration Testing is mostly outsourced and occurs when the development is complete.

There are mainly two reasons for this:

1 – Depending on the application, security loopholes and vulnerabilities could have serious consequences. Most regulated organisations want to buy assurance that their application can’t be compromised.

2 – Penetration Testing and cybersecurity are a specialised area and the employees don’t have the required skills and knowledge to perform penetration testing.

However, the problem with leaving security testing to the end is that serious issues could be reported too late in the lifecycle.

The delivery of software can be impacted and in some cases, even the architecture needs to be modified to fix security flaws.

We should no longer think of security as an afterthought. Security testing should be embedded within the project’s SDLC. We should be mindful of security implications from the onset of design and development.

In the continuous delivery model, when we are releasing software on a frequent basis (sometimes multiple times a day) it is impractical to outsource penetration testing. Every release could potentially open new loopholes into the system.

As a minimum, we should incorporate the OWASP Zap security testing tool in the development process which can automatically find security vulnerabilities as we develop applications.

Most development team members suffer from a lack of knowledge and skills in the cybersecurity domain.

The DevSecOps community attempts to address this problem by bringing individuals of all abilities to a high level of proficiency in security in a short period of time. Security is and should be everyone’s responsibility.

Leave a Reply

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