While my posts are typically more focused, Andy Green who is managing digital content at Varonis, thought it would be a good idea to share thoughts around the evolution of the threat landscape over the years: how did attack techniques evolve, the changes brought by the dark web and the economics of hacking, what we, the defenders are doing – wrong or right – and what we should do better.
So if you are into some techno-philosophical thoughts about cybersecurity, here it is:
I am back to blogging, but my blog posts now appear on the Varonis blog. I will keep publishing links to those posts here for my loyal followers.
This time:
The media coverage of NotPetya has hidden what might have been a more significant attack: a brute force attack on the UK Parliament. While for many it was simply fertile ground for Twitter Brexit jokes, an attack like this that targets a significant government body is a reminder that brute force remains a common threat to be addressed.
It also raises important questions as to how such an attack could have happened in the first place. These issues do suggest that we need to look deeper into this important, but often misunderstood type of attack.
If you are a member of the application security community, you are bound to know this hilarious xkcd cartoon. It is so good that it found its way to non-expert circles. I once got it physically framed as a birthday present from friends.
Like most of you, I though that this is a great way to explain SQL injection. For most of us, this is what it is. For a few, it is a real life problem
My dear friend Or Katz published an even more hilarious blog post outlining the challenges of someone who happens to have a first name which is an SQL keyword. His post is also a very good discussion of the use, or rather abuse, of signatures for web application security. A great and worthwhile read.
I have a very warm place reserved for the ModSecurity Core Rule Set (CRS). I created it a decade ago. Actually the first release in the readme file, labeled 1.1, is dated to October 2006, so this is an anniversary. And what a great present I got for the Anniversary from Chaim Sanders, Walter Hop and my dear friend Christian Folini: a brand new major release!
If you don’t know what the CRS is, a short introduction is due. Continue reading
Simply put, Web Application Firewalls are security controls designed to provide the best automated operational protection for HTTP applications, whether web based on mobile. What is “the best” protection, or even “sufficient protection” is not a simple question. As a result there is a spectrum of solutions for protecting web applications with varying quality and functionality. Which one can call itself a web application firewall is not an easy question to answer.
Probably the only way to define a web application firewall is to list the key features common to web application firewalls uniquely suited for protecting web and mobile applications and which would differentiate than other operational security controls such as intrusion prevention systems and network firewalls. The following sections touch on those key features of WAFs. A fuller discussion of the features will follow in later posts. Continue reading
If anything makes web applications security different, and more interesting, than traditional information security, those are threats to the application logic, i.e. attacks that abuse legitimate functionality. Such attacks often raise legal and ethical questions: if this is legitimate functionality, can it be an attack? Ethical questions a side, there is no question that click fraud, scraping and comment spam cause real pain and financial damage to web site owners.
The new OWASP automated threat handbook tries to sort out this field and define an ontology for web automation attacks and for countermeasures.
My own presentation on the topic takes a different approach: there is no real dividing line between valid and malicious automation. It is a continuum. I scored each such automation technique for “obviousness”, i.e. how clear it would be that this is automated and not and for maliciousness. Based on the scores I split the techniques into obviously malicious, accepted and borderline. So for example, given a 1-5 scale (1 being not obvious/not malicious, 5 being obvious/malicious):
Read the presentation to get the scored for all of them and learn what “Queue Jumping”, “auction sniping” and “web spam” are!
Wikis are a very strange animal. They break everything we know about information security, for example by allowing everyone to create and edit pages.
This presentation discusses this different philosophy of information security, presents its unique security challenges and tries to provide solutions for those.
(This is the first chapter of a Web Application Firewall Guidebook to be published in the next few posts)
Before getting into web application firewalls let’s review the problem they solve and alternative solutions. As web application security is essentially a software quality problem, resolving it require fixing the way we develop, deploy and operate software. This process is usually referred to as the software development life cycle, or SDLC for short. The security aspects of the SDLC process are called Secure Development Life Cycle, which confusingly has the same abbreviation: SDLC.
Ideally, fixing the security of web applications should be done at all SDLC stages as vulnerabilities are introduced in all stage. While it is better and potentially cheaper to fix issues early on, no quality assurance is perfect and bugs are carried on to following SDLC stages.
Since there is a cost for implementing security in any stage of the SDLC, when allocating resources we need to make a choice as to where to invest and how much. If any of the solutions outlined below was a silver bullet, the decisions would have been easier, however this is not the case. Is it better to invest a lot in educating developers and having a more secure code but neglect to test or protect the code in the operational environment? probably not, after all no code is vulnerability free no matter how good the developers were. On the other hand, should we only deploy a real time operational control such as a web application firewall? It would be unnerving to release buggy software no matter what automated solutions are there to protect it.
Let’s review the available application security solutions at every stage of the SDLC: Continue reading
As Google Apps become more popular in organizations, the security issue takes central stage. Interestingly, the technical aspects are the least of your worries, after all Google’s application security team is as good as they get. Many of the challenges are not technical in nature but rather legal and privacy issues.
Among the issues discussed in the presentation:
You can also find a video of the presentation here.
As a light weight alternative to web services, RESTful services are fast becoming a leading technology for developing mobile applications and web 2.0 sites.
At first glance, RESTful web services seem very different than web services and suspiciously similar to regular web technology. The similarity of RESTful web services to regular web leads to the notion that RESTful web services can be tested and secured in the same way.
However, this is a misconception. RESTful services share many of the security challenges of other web services technologies, but lack a formal structure to compensate for that. Specifically, testing RESTful web services is challenging as common pen testing attack surface detection and fuzzing techniques do not work.
This presentation presents the challenges and possible solutions for assessing RESTful web services security. Topics include :
You can download the presentation here or watch the video recorded at Source Seattle in September 2012 here.
