2017 has been a wild ride in the security world. This year we saw several high-profile breaches and cyber-attacks, the most notable being the Equifax breach and the WannaCry malware campaign.
While the outcome of these events is unfortunate, they provide us with valuable lessons to learn about enhancing our security. What did WannaCry and the Equifax breach both have in common? In both cases, the attack vector was a known exploit which had already been patched at some point before the incident took place. WannaCry spread by exploiting a vulnerability in SMB known as MS17-010 . A patch was released for this vulnerability in March, two months before the attack occurred. Attackers breached Equifax by exploiting CVE-2017-5638 . This vulnerability was also patched in March, two months before the breach occurred.
The fact of the matter is: applying updates is critical. Whenever a vendor patches a security vulnerability in their software, attackers (and researchers) can reverse engineer their changes and determine what it was that they fixed. It is not uncommon to see exploits published for vulnerabilities just a few days after they are fixed. From there, attackers begin scanning for sites that have not yet patched.
This is why it is important to apply updates as quickly as possible. Personal devices have gotten great at doing this for you. If you use Windows, you’ve no doubt been interrupted by your machine telling you that it’s time to install updates. Heck, even my Kindle updates itself. Why can’t our web application frameworks do the same? If you are a developer, I know the answer that is going through your head right now is probably, “because it will break prod!”
How can we apply updates automatically without breaking business critical applications? I don’t know the answer to that question, and I wish I did, but I believe that is a hurdle that we will need overcome to maintain secure web services and that one day we will do so. Until this happens, here are a few things that you can do to speed up the process of patching of your web applications.
- Maintain an inventory of all your production applications and the technologies / frameworks running on each them – with version numbers! When you hear about a new vulnerability affecting version X.X of framework Y, that will be all you need to know to tell if you are vulnerable.
- Have a policy on patching. Check for updates every X days. If there are any updates that have security fixes, then evaluate the severity of the vulnerability being fixed (most vendors have security bulletins, this is what they are for). Establish a required time-to-patch for each level of severity.
- When starting on a new project, take the ease of patching into consideration when choosing which technologies to use. If patching is difficult, and requires you to take down and rebuild your application, then consider using something else.
*** This is a Security Bloggers Network syndicated blog from Blog – WhiteHat Security authored by Brian Williams. Read the original post at: http://feedproxy.google.com/~r/WhitehatSecurityBlog/~3/BG_DbkO5fdM/