Whether you’re looking to build a new tech business, develop a new piece of software for a client, implement new technology within your existing company or build a new website for your organisation, creating and implementing new tech projects is always an exciting prospect. But, in the excitement of it all, it can be too easy to focus on the ‘interesting’ functional aspects of the project and avoid some of the more ‘mundane’, or less attractive, jobs until later down the line. The jobs you know you need to do, but which aren’t considered as exciting, interesting or transformative as the others.
Security is often one of these jobs and can be perceived by many as detrimental to the creative process. In fact, according to the EY Global Information Security Survey 2020, just 7% of organisations would describe cybersecurity as enabling innovation.
With such negative perceptions, it’s no wonder security can be left until the very last minute.
Take software development as an example, an industry we work closely with. Functionality and user requirements take priority within the development cycle – after all, you always want to deliver what your clients want. But security requirements don’t often feature within the essential functionality or even within the ‘nice to haves’. In most cases, security considerations only feature at the end of the development process, when clients are looking for final assurances before sign-off and go live. In some cases, it doesn’t feature in the development process at all and security requirements only surface once the application has gone live and issues start to arise.
No matter what the tech project, leaving security testing and security assurances until the last minute is a risky approach, especially when there are tight timelines to adhere to. What happens if testing can’t be completed in time due to the last-minute nature of the request? Do you go live without security assurances or delay release? Neither is ideal. What happens if last-minute security investigations find major issues within the project, issues that will take time to remediate?
Again, you can go live knowing you have issues present and take the risk, or delay and fix the issues. It’s not a great position to be in and it’s certainly not something you want to be telling the client or internal management at the very last minute of the project. Yet, it’s a situation we’ve seen happen time and time again when security has been left until the very end of a project.
So, next time you’ve got an exciting new tech-based project underway, how do you ensure you don’t come across security issues like those above?
Consider security as early as possible
Security by design isn’t a new concept and, whilst it has been adopted by many, it seems that security by afterthought is still the default setting for many organisations when it comes to tech projects.
Incorporating a security by design approach into projects may sound like a hassle for organisations, taking up valuable time, resources and effort, but those who neglect to consider security from the outset can often make easy prey for hackers. The effort is worth it, and you can make the process as complicated or simple as you like. The key is that you’re considering the security of the project at the earliest possible stage and therefore creating a more secure product as a result. Think of it like baking a cake: it’s far easier to add raisins into your cake mix before baking than trying to do it after you have finished.
You can eat your own dogfood, but should you mark your own homework?
When developing a piece of software or an application, it’s important to test its functionality as thoroughly as possible. To do this, development teams, as well as other in-house teams, will often ‘eat their own dog food’, using the software in the same way the customer would, helping uncover potential bugs before it makes its way into the hands of paying clients.
Conducting your own functionality testing in-house is one thing, but conducting your own security testing could be a completely different proposition.
First, testing can often sit with the development team, the very people tasked with creating the software. But do they have the correct skills to test it fully? They may have knowledge of security testing, the tools and approaches used, but can they interpret the results effectively or delve as deeply as a dedicated tester? It’s the same for ethical hackers; yes, they may well have knowledge of development practices, but many don’t have the skills to be a developer.
They are entirely different mindsets, one is creative, one is destructive, and you therefore need to adopt the right approach, if you are to be successful. In that case, using developers, or any in-house team, without the right skillset or mindset, may mean that issues are missed and may supply false assurances that things are fine, when in fact there aren’t.
The second issue is whether in-house teams are too close to the project and therefore may not be fully impartial in their testing. Having your work judged by an external expert is always a daunting prospect, but it’s far better to have an independent assessment of the situation, rather than run the risks of marking your own homework. As we always say, external security testing isn’t here to call your baby ugly.
Test as fully as you can within the constraints
With project resources tight, it can be all too easy to cut corners in areas which, while necessary, have less perceived benefits. Testing is one of these areas and, although any security testing is beneficial, not all testing, and not all assurances, are created equal. Companies have a variety of choices when it comes to testing, whether it’s conducting it in-house, which we’ve discussed above, vulnerability scanning or penetration testing. They can choose to conduct a test at the end of the process, during development or ideally a combination of both.
They also have choices when it comes to the scope and approach of those tests. Is testing to be focused on specific areas of the project, the ones that are critical or do you take a wider view? Should you only consider the threat from external sources or consider the potential damage that could be achieved, if a malicious threat was to obtain internal access?
Compromises often must be made and there have been many occasions where limitations mean full, in-depth testing just isn’t possible. But testing should always be as thorough as possible within your set limitations, giving you the upmost confidence in your defences.
Yes, you can always get cheaper testing services or limit the scope of testing to save time, and still get the sign-off you need, but, if there is then a security issue and it’s found that you scrimped on testing, then the fallout will probably cost more than the testing ever would have.
Article originally published in Computing Security Magazine
