I asked my colleague Jesper Krakhede in the Security practice if he would share some of the thinking he discussed with me in respect to the challenges he sees and the need for us to change our attitude and responses in applying security in our new world:
Working in the field of security is like waking up every morning and be surprised you are still alive. Something that is foolproof and impossible to crack one day just crumbled to dust during the night and then you have no more happy thoughts for a while, or… do you? With the emerge of APEG the distribution of patches is attacked. It is not unknown that by reverse engineering a patch you could find the possible ways to exploit the original code. APEG only does it faster and cheaper. That’s automation for you!

What are the security implications of this? Hopefully you have implemented layered security already and better yet moved security to information level as proposed in Jericho. This still means that a large bastion in security has to start moving faster. Having patch management processes running for 30 days is not good enough anymore. The study even shows that 24 h could be too long. The writers of the article argues that there are several ways to combat this problem with encrypting patch delivery, peer-to-peer delivery and other ways to create a faster network because it is in the speed of the infrastructure the problem the APEG creates a vulnerability.
Still, if you have a requirement to do patch review before installing, you could be affected even if you do your best. Sometime during this process you probably start wondering why you have to patch in the first place. Why can´t the developers write better code? And here are the bigger implications of APEG? With the possibility of sub second exploits developers, architects, engagements managers and engineers have to start working securely. Adding security in the end as a gadget that blinks is not acceptable anymore. Security has to be included in the beginning as quality already is. Security is just an aspect of quality and we all want to delivery good quality solutions, right? Even if you are a software developer, outsourcing partner, a web merchant, a bank or in public, to name a few, security has to be there.
The time when hacking was university stuff and viruses were a fun thing with letters dropping of the screen is over. Today industrial espionage, organized crime and fraud is all over the map. By starting to create solutions that are secure by default, hand them over to an IT-department that operates secure by default and has a management that states that information should be secure by default APEG and likes have no chance to succeed. To be able to create secure solutions we have to change our structured development flow to a more agile process. Going from the slow process of ‘Steady State’, ‘Idea of change’, ‘Change’ and back to a ‘Steady state’ with decision points, reviews and such to a real time testing and security monitoring takes a new mindset. Security should always be present. Every line of code, every new architecture should be constantly reviewed from a security perspective. More agile development also opens up for a more agile use of IT. It will be easier to create MaschUps when you are sure that the code is safe in the morning, during the day and in the evening. Security has to be flexible, constant and always there. More agile processes also calls for a faster change management with small and controlled deliveries that are transparent and easier to understand hence shorten the need for testing.
The best part? By securing the information by default and moving security to information level you could put your whole database on internet and still be confident that only the right people could access it. Security is a state of mind and introducing this is probably the biggest implication of all.