Entropy has been described as the measure of disorder of a system. The Second Law of Thermodynamics, as defined by Rudolf Clausius, states that the ‘Entropy of the universe tends to a maximum’, which means that the universe is heading towards maximum entropy, or maximum disorder. Entropy can be seen in everyday life, ice melts, metal rusts and food decays. In these cases, it is irreversible, you cannot un-melt ice, or un-rust metal or un-decay food. However, it is possible to slow down entropy. For example, you can refreeze water, treat bare metal and preserve food in a fridge or…Continue readingSecurity knowledge entropy
Author: Glenn Wilson
In this final instalment of articles exploring security test automation, I take a closer look at Software Composition Analysis (SCA). Open source software has grown considerably over the last few years. As engineers struggle with the writing of code that meets ever-increasing demands of the business, they do not want the distraction of writing logic to integrate those business rules into the architecture of the application. Instead, they want to use code that already does boring stuff so they can focus on adding value to their products and delivering solutions faster. The result is the proliferation of open source software…Continue readingSecurity test automation part 5: SCA
In previous articles, I wrote about the Application Security Testing tools SAST, DAST and IAST, which are designed to help engineers fix problems during the development lifecycle. In this article, I write about a technology designed to protect applications in a production environment. This technology is known as Runtime Application Self-Protection (RASP). Once an application has been deployed into a production environment, the level of real-time protection moves from proactive preventative measures associated with developing secure products, to reactive remedial measures. For example, traffic to your applications can be monitored by Web Application Firewalls (WAF) for potentially malicious activity and…Continue readingSecurity test automation part 4: RASP
In my previous two articles in this series on security test automation, I gave a brief insight into SAST and DAST. In this article I take a closer look at Interactive Application Security Testing (IAST), a relative newcomer to the security test automation scene. The key difference between IAST and the two previous types of application security testing is found in how the tools interact with the products being tested. SAST and DAST are active tools: in order for them to scan code, they need to be triggered either from the Integrated Development Environment (IDE), or from within the CI/CD…Continue readingSecurity test automation part 3: IAST
In part one of this series of articles, I wrote about Static Application Security Testing (SAST). In this second part, I turn my attention to Dynamic Application Security Testing (DAST). Unlike SAST which analyses static application source code, DAST analyses the application dynamically while it is running. Immediately, this pushes the operation of the dynamic analysis tool further right along the delivery pipeline than its static counterpart. Ideally, it needs to do its work after the application code has been integrated and is ready for functional testing. DAST has evolved over the years. When I first came across it, vendors offered a…Continue readingSecurity test automation part 2: DAST
A question that comes up frequently in my capacity as a DevOps / Agile Security consultant is: how do we integrate security test automation into our environments. There is a lot of information on automated security testing tools, but unfortunately, the vast majority of it is written by the companies who produce and sell the tools. Their literature paints a very healthy picture of how all the tools are integrated. In September 2019, I attended a DevSecOps event in London in which a small number of application security testing vendors were invited along to talk about how they secure their…Continue readingSecurity test automation part 1: SAST
Password hell!
You know what it’s like, you have just hit the ‘Register’ button on a website and you’re being asked to provide a password to set up an account. So you try to come up with something that you can remember and meets the website’s password policy which dictates the characters to use and its minimum length. I have posted a link in previous LinkedIn updates of a video of British comedian Michael McIntyre giving a perfect example of the thought process you may go through to come up with a password. It’s worth watching because it is very funny, but…Continue readingPassword hell!
Data is big! Big data is even bigger! Organisations across the world collect a lot of it: customer data, employee data, supplier data, competitor data. Organisations collect customer data in order to gain advantage over their commercial rivals. They use it to learn how customers spend money: which products they are likely to buy based on their spending habits, demographics, location, politics, what they eat and drink and who they socialise with. This information is powerful: it fuels the engine behind targeted advertising to accelerate sales. Furthermore, organisations collect other data during the course of a transaction, such as credit…Continue readingCustomer data: a moral obligation to keep it secure
Introduction When I first encountered the Agile framework, I was awestruck by how software engineering teams worked so differently from what I had been used to and achieved much better results than I had seen before. I saw developers work in groups of two or three at the same workstation for hours on end, I watched Post-It notes move rapidly across a whiteboard labelled with ‘To Do’, ‘Doing’ and ‘Done’, and I viewed monitors showing the results of hundreds of unit tests running constantly and rarely failing. The notable absence of multi-paged design documents and architect drawings, the presence of…Continue readingAgile – 5 mistakes organisations make
Listen to a news report or read a news headline in the paper about a security breach and you are likely to hear from the affected company that it was a victim of a sophisticated attack. The reason for this is simple: no-one wants to admit that they were actually the victim a rather simple attack. They like to portray their organisations as being so secure that it took a bunch of complex measures by a hacker to breach their systems. In reality, many sophisticated attacks rely on hackers identifying easily exploitable vulnerabilities either within the software or, more likely,…Continue readingSophisticated attack? Really?