Day: May 11, 2016

With every day that passes it seems that cybersecurity becomes a bigger and bigger issue for businesses and citizens. General and specialized media are flooded with stories on threats and attacks. On top of that, countless niche cybersecurity vendors out there are fighting to communicate how their products can solve most cybersecurity problems. It all contributes to a collective fragmentation of views on what cybersecurity actually is, creating a fog of information.

In the meantime, executives, security managers and specialists are looking to cut through this fog to find proper and holistic navigation tools. A disciplined information security approach suggests adopting the established views for guiding maps, such as ISO 27001, the Federal Information Security Management Act (FISMA), PCI Data Security Standard (PCI DSS), and new ones, such as the US Cybersecurity Framework. Unfortunately, they are not sufficient to provide enough relevant knowledge for establishing cyberresilient organizations, data centers and information systems.

What is missing in all of this are the connections between actual attack techniques, vulnerabilities, threat actors and further detailed analysis of the domain.

So how to fill this gap properly?
I wish I could say that my beloved Center for Internet Security’s (CIS) Critical Security Controls (CSC) is the right answer. Unfortunately, while it is a useful instrument, it does not provide sufficient guidance.

Recently the European Union Agency for Network and Information Security (ENISA) published its Threat Landscape 2015 (ETL 2015), and I was pleased with what I found in it for cybersecurity strategists and practitioners. For the last two years I have referred people to ETL, also Verizon’s Data Breach Investigation Report (DBIR) and CIS CSC, because they all offer relevant, independent sources for strategic, operational and tactical guidance for cybersecurity.

What is so special about these reports? Here are my thoughts on the recently published ETL; hopefully they will inspire you to read the reports if you have not already.

1. ETL 2015 (and 2014) provide measurement of the landscape of cybersecurity, connecting strategic and tactical views;
2. ETL 2015 offers mitigation vectors (controls) for the Top 15 threats. For example, CIS CSC provides aggregated mitigation vectors for all threats in prioritized and increased sophistication levels. Such CSC aggregation is good for overall enterprise vision, however it dilutes details of a particular threat, which are relevant to motivate and prove that a threat can be handled adequately;
3. Cybersecurity vendors publish quarterly and annual reports on threat analysis; however they have internal conflicts—covering only information that is relevant to vendor product portfolio. ETL 2015 mitigates this conflict nicely by providing links to relevant deeper vendor analysis for particular top threats. I find it so elegant and a valuable resolution!
4. ETL 2015 provides a separate visual Top 15 threats poster – allowing it to be used as an instrument for discussion on how this information is relevant for a particular environment;
5. I have been involved previously in a few threat classification efforts. I am happy to see that ETL 2015 has issued their Threat Taxonomy in a mindmap, and also in an elaborated Excel format (after opening Excel, for it to be readable, hide the document comments). It can be a great tool to validate your views and see if any gaps remain in your cybersecurity defense architecture. It also allows you to link to an IT infrastructure resilience theme.

DBIR gathers cybercrime facts, even while it is not clear to what extent European law enforcement agencies can legally analyze cases and share anonymized data. DBIR provides great analysis on what should be changed to improve resilience to cybercrime, and it maps practical guidance to CIS CSC. I hope that future ETLs will connect to CIS CSC as well, and to COBIT and ISACA’spublications.

At the end of the day, most organizations have to work through the fog of hysteria on cybersecurity to choose their own strategy for cyberresilience. I hope that these resources will be valuable anchors for you and your organization to evaluate and choose your own way.

Benetis will present Cybersecurity Skills Audit at EuroCACS 2016 30 May – 1 June in Dublin.

Dr. Vilius Benetis, CISA, CRISC, CEO, NRD

[ISACA Now Blog]

Have you ever gone to see a movie that would have been amazing if not for one person? The plot was engaging, the dialogue was well-written, and there were strong performances from most of the cast. But there was just that one actor who simply didn’t live up to the rest of the film, and it made every scene he was in that much worse? Simply put, that actor was bad, and brought down the whole operation.

That idea of the “bad actor” can be applied to Internet clients, as well. Fortunately, you’re not hurting any feelings by sussing them out: the bad actors are usually automated processes that can harm your systems. The two most common forms are content scrapers, which dig into your content for their own profit, and bad bots, who will misrepresent who they are to get around any restrictions stopping them.

We’d all like to believe that everyone accessing content will use it appropriately. Unfortunately, we can’t always assume the best, and being proactive in dealing with these bad actors will reduce security threats to your infrastructure and apps.

Even better, blocking bad actors will also lower your operating costs. When these bots access your content, you’re serving the traffic to them, whether you want to or not. That adds more to your overall costs. By blocking them, you’re restricting traffic from a number of undesired sources. Luckily, AWS has a pair of tools you can combine to say goodbye to these bad actors: Amazon CloudFront with an AWS web application firewall (WAF).

With AWS WAF, you can define a set of rules known as a web access control list (web ACL). Every single rule contains a set of conditions, plus an action. Any request that’s received by CloudFront gets handed over to AWS WAF for further inspection; if the request matches, the user can access the content as attempted. If the request doesn’t match the conditions in a specified rule, the default action of the web ACL is taken. These conditions will remove quite a bit of unwanted traffic, as you can set filters by source IP address, strings of text, and a whole lot more. As for the web ACL actions, you can count the request for later analysis, allow it, or block it.

Perhaps the best attribute of the WAF is that you can smoothly integrate it within your existing DevOps, and automate workflows to react. Since bad actors are always switching their methods to mask their actions, your proactive detection methods must constantly change, as well. Having those automations in place is immensely helpful in finding bad actors and restricting their access.

There’s a great walkthrough of how to set up this solution on the AWS Security Blog, step-by-step. Feel free to check it out for more information, or get in touch with us if you have any additional questions. And for AWS customers that need even more than what the AWS WAF has to offer, there are services that are complimentary to the AWS WAF that provide enhanced protection for business critical applications on AWS. You won’t even need to thank the Academy when all of those bad actors are removed.

David Lucky, Director of Product Management, Datapipe

[Cloud Security Alliance Blog]