Zane Lackey: “You should not invest in security, only to comply with the law”

The role of the head of information security is constantly increasing, moving from the traditional “watchman” to a more universal corporate-wide curator of security issues. Today our guest is Zane Lackey, one of the most important “white” hackers in the world , the author of such books as “Mobile Application Security” and “Hacking Exposed: Web 2.0.” Lucky is currently the co-founder and chief security officer (CSO) of Signal Sciences , which offers a platform for protecting web applications, as well as a board member of the Internet Bug Bounty Program and Open Technology Fund .

Despite the fact that new infrastructures, services and applications are constantly being created, such “simple” things as security problems on the end devices or the lack of two-factor authentication systems continue to be the cause of many global attacks that create news stories in the media.

We began our interview by recalling the days when Zane was a “white” hacker.

Panda Security (PS): What techniques do you use to detect vulnerabilities and identify threats to avoid an attack?

Zane Lucky (ZL): Returning to my “pentesting” days, which were already quite a long time ago, the most common things I was looking for were the axioms that were made during the development of the system. Then I looked for those that could have been violated. Having embarked on the defense side, I took this way of thinking, thinking about how to strengthen the development team and the DevOps team. This was one of the most serious conclusions I made for myself: moving from a “white hacker”, security consultant, pentesting to CISO and building a security company, I really focused on how to give the team of engineers the maximum possible vision what happens in production.

PS:How do programs like Internet Bug Bounty help fix detected vulnerabilities? What do you do after another security hole is discovered?

ZL:I know that there have been some changes in the Bug Bounty program lately, so I don’t want to say anything that may seem incorrect here, but I think it’s important to try to get in touch with the researchers who come. Because very often you get a report that partially or not at all contains the information that is necessary to reproduce the incident. Therefore, if it is possible to say: “Hey, here are five bits of information that we need so that we can address this to the team of the corresponding service or application”, then this will help communications on both sides. And at the same time, trying to return to the researchers, because this is not only a “black box" for them. Trying to be as transparent and open to both sides as possible is what really brings Bug Bounty to a good experience,

I think anyone who runs their Bug Bounty program is trying to see things from every angle. You see everything: from systems that you did not know about, to almost all types of vulnerabilities, even those about the existence of which you did not suspect. Therefore, I really firmly believe in the value of such programs, and I think that they complement pentesting very well. Their combination can really help most security programs. The reason I love Bug Bounty programs, where there is such a combination with pentests, is that this approach allows you to orient your pentests to very specific areas instead of trying to test everything in a row, which may not be enough time. So you can use your bug bounty programs to try and get wide coverage,

PS: Recently, the NHS hired hackers to detect cyber threats . Do you think that “ethical” hackers are not interchangeable in modern companies in order to avoid security incidents and strengthen their protection?

ZL:Every organization needs to think about how people actually attack your systems. So, white hackers, pentesting and bug bounty are all parts of this. Those. this is not the whole story, but they are part of it. You don’t want to do security just to meet some legal requirements, or just trying to check how well all available protection modules work. I urge people to always keep in mind one thing when they think about creating a security program: how could a hacker actually attack my organization? And never forget this to develop your existing protection programs. So “white” hackers, bug bounty programs and all the different ways to test your system can become a very powerful feedback loop. Because they can show when your systems will be attacked, "That's where they went." And this can focus your efforts to protect.
So, I really firmly believe in a balance of attack and defense and their use for the development of each other, and not in trying to do one in isolation from the other.

PS: How can you implement DevOps to make companies safer?

ZL: I believe that using DevOps and Cloud can make you safer. The reason for this lies in the fact that in any development methodology, you will still have vulnerabilities. As soon as you realize this fact, you will see a simple logical conclusion: development technology that allows you to respond as quickly as possible will allow you to become more secure. In the old model, the problem was that it was not possible to respond quickly. That's why DevOps, Cloud, and the move to Agility can really make you safer.

PS:What lesson can we learn from mass data theft cases like Equifax that occurred due to a web application vulnerability?

ZL:I would say that there are two conclusions that we must draw from data breaches observed every day. One of them is that in 99% of cases, the causes of incidents are quite common errors: weak password, not updated system or application, infection of the end device with malware, etc. Therefore, returning to the previous comment, I would advise all organizations to think not about “insane, state-sponsored zero-day threats that are very complex”, but to focus on simple things: how do you control malware on your end devices? How do you use two-factor authentication on all your accounts? And how do you ensure security at the web application level?

And all because, in my opinion, the second conclusion follows regarding security breaches, which we are all just beginning to realize, but which we have been seeing for the last few years: historically, security risks have been associated with the level of infrastructure and network, and therefore we always thought that firewalls, IDS, and similar things could soften them. But over the past few years, risks have shifted to the application and end device level. Therefore, understanding where the risks are actually located is the number one lesson that we must thoroughly learn, as our entire industry has done now, as an example of the security breaches we see.

PS:Do you think companies are ready for the new European legislation on the protection of personal data (GDPR)? What should they do to comply with all the requirements of this new law and protect their data?

ZL: When new legislative requirements come into force, there is always a lot of concern about this, because no one is ever sure how it will actually be. So I think that at first not everything will be clear, but then you will see the emergence of products and services that will help to cope with this, after which there will be a clearer idea of ​​what the auditors pay attention to and what steps really need to be taken within this .

Safety and compliance with the law are two separate issues that sometimes overlap a bit. Therefore, simply protect your data, and do this not only because you need to comply with some requirements of the law, but you must ask yourself: how do I protect my end devices? How do I protect my web applications and my APIs and other things at the application level? Because these are exactly the two places where you have the most risks. So, you should focus on ensuring their visibility, implementing effective malware controls on end devices, implementing two-factor authorization on all services, where possible, and then on ensuring full coverage and visibility of the application level in order to protect them.

PS:In terms of application security, do you prefer security through internal programming or external security?

ZL: My answer is both this and that. To effectively protect applications, you are thinking about how to eliminate as many vulnerabilities as possible during the development phase, but at the same time you acknowledge that vulnerabilities will always exist. So you are trying to combine visibility with security in the code, but you are not just doing it in order to scan for errors once, and then after the application is released, simply ignore it while it lives on the Internet. By the way, I think this was one of the most basic SDLC errors in the last ten years or more.

The main similarity that I see among organizations trying to do everything right is that they try to eliminate errors before the release of their applications. They acknowledge that there will always be vulnerabilities, and therefore they invest heavily in providing visibility of how these services can be attacked during the operation of their applications, and therefore they try to provide this visibility directly to DevOps developers and teams. As a result, they can effectively use this information and not rely entirely on security specialists to protect the services they create.