Zane Lackey: “You should not invest in security, just to meet the requirements of 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. Currently, Lucky is the co-founder and chief security officer (CSO) at Signal Sciences , which offers a platform for protecting web applications, as well as a board member at the Internet Bug Bounty Program and the Open Technology Fund .

Despite the fact that new infrastructures, services and applications are constantly being created, such “simple” things as security problems on end devices or the absence 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, recalling the days when Zayn was a “white” hacker.

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

Zayn Lucky (ZL) : Returning to my “pentesting” days, which were already quite long ago, the most common things I was looking for were the axioms that were made when developing the system. Then I searched for those that could be broken. Having taken the defense side, I adopted this way of thinking, thinking about how to strengthen the development team and the DevOps team. It was one of the most serious conclusions I made for myself: moving from a “white hacker”, a security consultant, pentesting to a CISO and building a security company, I really focused on how to give the engineering team the best possible vision of what happens during production.

PS: How can programs like Internet Bug Bounty help fix detectable vulnerabilities? What do you do after the next security hole is detected?

ZL: I know that recently there have been some changes in the Bug Bounty program, so I don’t want to say anything that may seem incorrect here, but I think it is important to try to get in touch with the researchers who come. Because very often you get a report that partially or does not contain information that is necessary to reproduce the incident. Therefore, if it is possible to say: “Hey, these 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 the communications from both sides. And at the same time, trying to return to the researchers, because it is not only a “black box” for them. Trying to be as transparent and open as possible for both parties is what really leads Bug Bounty to good experience, both for researchers and for companies that work with them.

I think anyone who runs their Bug Bounty program tries to see things from all sides. You see everything: from systems that you did not know, to almost all types of vulnerabilities, even those that you did not know existed. Therefore, I really firmly believe in the value of such programs, and I think they very well complement pentesting. Their combination can really help most security programs. The reason why I love the Bug Bounty program, where there is such a combination with pentest, is that this approach allows you to target your pentest on very specific areas instead of trying to test everything that may not be enough time. So you can use your bug bounty programs to try and get a wide reach, and you can use your pentest to close a specific area carefully.

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: In every organization, you need to think about how people actually attack your systems. So “white” hackers, pentesting and bug bounty are all parts of it. Those. it's not the whole story, but they are part of it. You do not want to do security just to meet some legal requirements, or just trying to check how well all the available security modules work. I urge people to always keep one thing in mind 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 be 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 protection efforts.
So, I really firmly believe in the balance of attack and defense and their use for the development of each other, and not in trying to make one in isolation from the other.

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

ZL: I believe 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. Once you become aware of this fact, you will see a simple logical conclusion: a development technology that will allow 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 moving to Agility can really make you safer.

PS: What is the lesson we can learn from cases of massive data theft like Equifax, which occurred due to the vulnerability of a web application?

ZL: I would say that there are two conclusions that we have to draw from the data integrity 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, malware infecting the final device, etc. Therefore, returning to the previous comment, I would advise all organizations to think not about “insane zero-day threats sponsored by states that are very difficult”, 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, here follows a second conclusion regarding security breaches, which we all are just beginning to realize, but which we have seen for the past few years: historically, security risks have been associated with the level of infrastructure and network, and therefore we always they thought that firewalls, IDS and similar things could soften them. But over the past few years, risks have shifted to the level of applications and end devices. Therefore, an understanding of where the risks actually lie is a lesson number one that we have to learn well, as our entire industry has done now, using the example of the security breaches we see.

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

ZL: When new legal requirements come into force there are always a lot of concerns about this, because no one is ever sure for sure how it will all 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 are paying attention to and what steps need to be taken within this framework. .

Security and compliance with the law are two separate issues that sometimes overlap a little. So just protect your data, and do it not only because you need to comply with some requirements of the law, while you have to 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 to protect them.

PS: In terms of application security, do you prefer security through programming from the inside or security from the outside?

ZL: My answer: both that, 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 recognize that there will always be vulnerabilities. So you try to combine visibility with protection in the code, but you do it not just to scan for errors once, and then just ignore the application after the application is released while it lives on the Internet. By the way, I think that this was one of the most basic mistakes of the SDLC over the past ten years or more.

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