The present Security State of many networks is a pretty sad situation. We are regularly seeing breach discovery times in excess of 200 days, with the discoveries often made by external parties. Those figures are based on the breaches that we know about. I’d would suggest those figures are just the tip of the iceberg.

This is a dreadful situation which simply says that many organisations DO NOT HAVE either sufficient ‘visibility’ into their internal infrastructure, or are not able to effectively process, correlate or analyse the data which does exist.

There are many people in the industry openly stating that the attackers have the advantage. I would not try and argue this point, but there is a lot that can be done. If we view security technologies from a Force Multiplier perspective, there are some technologies which provide only a marginal benefit (compliance activities perhaps.. IMHO), while others provide a very significant advantage to the defender.  

I believe that Security Analytics has the potential to have a profound effect on the security business and provide the defenders a very significant advantage. Effective Analytics providing detection capability, should enable a reduction in those statistics from hundreds of days to hours or minutes.

In the last few years we have seen an explosion in Big Data technology with many Open Source tools now being freely available. The scene is young and changing rapidly. But there are many opportunities for people in Security roles to gain exposure to these technologies. While some investment is required, it is possible to enter this domain at low cost.

At present Security Analytics tools are in their infancy. There are a lot of security companies using the buzzwords of Data Science, Machine Learning (ML) and Artificial Intelligence (AI), with very little to no detail on how they are being used or what capabilities are achieved. In reality most are just performing Correlation and basic statistics. With that said, those activities in themselves are very worthwhile. Coupled with some good visualisations, there is a lot of value in doing just those two things.

To lift the hood on some of the terms used in the Security Analytics Domain;

  • Statistics – is quantifying numbers.
  • Data Mining - discovering and explaining patterns in large data sets.
  • Anomaly detection - detecting what is outside of normal.
  • Machine Learning – learning from and making predictions on data through the use of models.
  • Supervised Machine Learning – The initial input data (or training data) has a known label (or result) which can be learned. The model then learns from the training data until a defined level of error is achieved.
  • Unsupervised Machine Learning – The input data is not labelled and the model is prepared by deducing structures present in the input data.
  • Artificial Intelligence -  automatic ways of reasoning and reaching a conclusion by computers.

Mathematical skills in Probability and Statistics, including Bayesian Models, as well as Linear Algebra are heavily used in these domains.

Today there are an increasing number of security data and telemetry sources available for analysis. These include various security logs from hosts, servers and network security devices such as firewalls, IDS/IPS alerts, flow information, packet captures, threat and intelligence feeds, etc. As network speeds and complexity has increased, so has the volume of the data. While there is a vast amount of security data available, identifying threats or intrusions within this data, can still be a huge challenge.

From my recent research into this space, I can conclude Security Analytics is a hard and complex problem, with the necessary algorithms being literally rocket science. To build any sort of Security Analytics toolsets, it is essential that detailed security domain knowledge be coupled with a knowledge of Big Data and Data Science technologies. There are currently very few people who possess both skill sets, so forming small teams will be essential. While this is a big and somewhat complex field, this fact should not put people off starting. Like any new technology, there will be a learning curve.

Suggestions going forward - I always like to provide some actionable recommendations out of any discussion.

Before you can analyse the data, you need to have the data and easy access to it.


Establishing a Security Data Lake.

To address the storage of security data, some organisations are now creating a centralised repository known as a Security Data Lake. This should not be seen as an exercise in replacing SIEM Technology, but an augmentation to these systems. On this topic, I would refer people to an excellent free O’Reilly publication by Raffael Marty, located at;

Data Lakes are often Hadoop clusters or some other NoSQL database, many of which are now freely available. Establishment of a Security Data Lake should be a starting point.


Look to closely monitor your ten to twenty most critical servers.

There needs to be a starting point and monitoring a set of key servers is an excellent and practical starting point.  There are many statistics that can be monitored – root/admin logons, user usage statistics, password resets, user source addresses, port usage statistics, packet size distribution, and many others. Start by visualising this data and use it as an operational tool. Security Analytics will mature over time, getting started provides operational experience that will only grow over time.

Apache Metron ( ) and PNDA ( ) are two Open Source projects which could potentially be a starting point for your organisation. Both are worth a serious look.


Last week, the United States and Canada issued a joint advisory on the threat posed by crypto based Ransomware. The advisory followed a string of high-profile incidents which had affected a number of hospitals both in the US and other countries.

The CERT advisory can be viewed at:

The pervasiveness of this threat is demonstrating just how many organisations are clearly completely vulnerable to this type of threat, often with severe business impact.

While it is clear that the Malware problem is massive. It has been well over a decade since we have seen any form of large scale destructive Malware. Back in 2004, I spent some time in New York City performing a consultancy for a then large financial institution in the wake of a destructive worm infection. On a Friday evening, an Internet Based Worm (which I won’t name here) penetrated their internal network spreading widely and randomly erasing hard disk sectors throughout the organisation. While it was contained, the damage was significant. Fortunately, they had the weekend to recover from backups and restore operations. Had the event occurred at another time, the business Impact may have been in the billions of dollars!

Around that time, and following high profile events like SQL Slammer and Blaster, there were many people, including myself, greatly concerned about the possibility of a large scale destructive worm outbreak and the resulting potential economic impact. Fortunately, the high profile Internet worm trend died off, simply because there was no money to be made and significant personal risk existed for the authors of such Malware. Ransomware is just another form of Malware….. but with a significant financial return! Given the fact so many organisations are openly vulnerable to Ransomeware, again concerns me greatly.

The CERT Advisory recommends a range of fairly fundamental preventative security measures, such as adequate backups, system patching, etc. While those measures are strongly recommended, I would also highlight the importance of a robust network security architecture. Having previously worked with many customers who had been affected by those events, some severely, some far less so, it became very clear that those who had robust network security architectures, and mature operational procedures, were far less impacted.

In light of the current trend and growth of Ransomware, I would additionally highlight the importance of Network Security. This includes the use of Zoned Security Architectures, quality Firewalls, IPS (with auto updates), Network AV and Day-Zero malware detection systems. While there is no silver bullet, these approaches can significantly reduce your organisations risk profile.

I can’t see this problem going away any time soon. I predict it will get worse before it gets better.


To everyone who attended my presentation on Friday 11 March 2016 at the Novotel in Brisbane, thank you for the opportunity.

The presentation material can be downloaded from Here.

For those of you interested in the topic of Cybersecurity and Network Security Architecture. I have just posted two White Papers under Knowledge Base.

Background - My primary focus these days is keeping corporate and government networks protected within a constantly changing Threat Landscape. While there is a lot of very good information available on many aspects of Information Security, I could not find much good information on Network Security Architecture and Design, and definitely very little which is up-to-date. 

To help address this gap, I have written two White Papers on this subject area:

  • The first covers the fundamentals of Network Security Architecture. 
  • The second then moves on to discuss the changes in recent years, and what this means for Security Architectures in 2015 and going forward. In particular, I discuss Architectural Foundations and then look at 'operationalising' security, the need for a new mind set, the role of Analytics and considerations for deploying 'Cyber Kill Chains'. I have attempted to capture the big issues and provide a number of technological and policy recommendations.

Please view them under 'Knowledge Base' or via these links to the PDF versions:

White Paper 1 - The Fundamentals of Network Security Design - Download Here.

White Paper 2 - New Considerations for Network Security Design - 2015 - Download Here.

There is about 80 pages of information, with more in the works. I hope it is useful and welcome feedback.

Penetration Testing versus Security Architecture Assessments


It is worth making comment on the positioning of a penetration test and a security architecture review or assessment. Penetration testing services are available from many organisations and are generally well understood and widely utilised throughout the security community.


Firstly, both penetration testing and architecture assessments are complementary to each other as they achieve different goals and can uncover different issues. 


The primary goal of a penetration test is to find vectors to break into an organisation and gain access to key assets in a controlled and ethical manner. At the most fundamental level, Penetration tests are performed in much the same way as a malicious hacker would attempt an intrusion. They looks for open attack vectors and vulnerabilities which can be exploited. The goal being to find them and close them ahead of a malicious hacker.


Penetration tests are a practical simulated attack on the organisation. In many cases penetration tests will achieve a successful intrusion or intrusions through one or more exploitable attack vectors. In these cases the reason for the successful attack can be analysed and remediated. Commonly this will mean updating an operating system or application to close an open vulnerability. Such findings may well be the result of a process problem, sometime small, for example a single patch was missed during a patching cycle, but sometimes more significant, for example, a larger scale inadequate patching or software maintenance process.


Penetration testing services generally do not look at the underlying architecture. There are many organisations who have architectural deficiencies, but with no open attack vector at the time of a penetration test. In these cases, the penetration test will likely not pick up a high risk issue in the network, should it exist. Let me provide an example. Let's assume that a network has a poorly designed or outdated Internet DMZ architecture where a server, if successfully exploited and owned, would provide open access deeper into other parts of the network. Say at the time of the penetration test that server was at recent patch levels with no known exploitable vulnerabilities. Then a penetration test would not detect any issue. At a later point in time, a critical vulnerability is announced which now leaves the previously tested server vulnerable. We now have a fully exploitable path for an attacker to gain entry deep into the network. More importantly, this is one of many situations which would not have been detected through a penetration test alone. 


I am not trying to suggest that penetration testing is not a necessary or valuable service - it is. But the limits of what it can achieve should be well understood. 


Architecture analysis, architecture reviews and assessments provide a different approach with different goals. This approach is entirely complementary to penetration testing services. An architectural analysis, as the name suggests, is designed to find architectural issues which can allow an intrusion under certain conditions, or constitute a high risk deployment. Today, many networks have grown organically, or have had multiple groups of personnel working on the network throughout its life. All too often new services are deployed with tight timeframes, i.e. The "just get it working" approach. As a result sub-optimal or poor architectures get deployed and can remain for many years. These are often time bombs waiting to be exploited and can pose very significant business risks.


Sound security architecture involves many fundamental design principals. Dramatic changes have occurred in the security landscape over the last few years, and the use of sound security  architecture principals is now more important than ever. In in this day and age, circa 2015, newer architectural approaches such as Kill Chains are being recognised for their benefits. Adopting these architectural approaches is occurring in thought leading organisations which solid outcomes.


I hope this brief blog post has helped position the benefits of architectural assessments in comparisons to penetration testing.