How AI and automation will impact cybersecurity strategies
My real first experience with data security came in 2000 when my personal information was exposed on a website where a disgruntled employee was able to steal an HR spreadsheet that had hundreds of people’s names, DOB, SS#, addresses and how much they earned.
Even though we have moved PII to a “more secure” storage method, those storage solutions and access to them are still insecure. And this has been largely proven in the massive breaches of 2018.
We need to become better stewards of data that impacts people. I read an article introducing an InfoSec Color Wheel, and they discuss involving and integrating red teams with DevOps. I think that is a great idea to move quicker towards a more secure application development process that will ultimately impact the safety of our data.
AI (For good and bad)
I had one potential customer tell me, “thank you for not saying that this product uses AI.” I found that to be interesting. More and more applications in several different verticals are gravitating towards AI. Why is that? I feel that it is due to the lack of skilled people and the speed at which humans can work. I would like to think that we will need and use AI to make decisions on our behalf. I think that AI will help move the sticks in security from remedial tasks to more extensive changes. Unfortunately, AI will also be used for bad purposes too.
A few years ago, we saw how automation started to take hold of DDoS attacks, and in my opinion, that is the first step in introducing AI into an attack. As a matter of fact, there is code available now that can push the envelope for DDoS and loop AI attacks. I wouldn’t be surprised if Malware morphs, with the help of AI, in a way that will detect and thwart current prevention measures.
More Automobile Hacks
A little off my beaten path and outside of my expertise, but as more and more computer and electronics are put into automobiles, the more it will expose security holes in software and hardware. With the pressure to gain market share and sales for automobile manufacturers, they will skip steps in testing the new “gear” that they attach to vehicles. Let’s see what fun new things come out of Def-Con 2019. ;-) If you’re interested in understanding more, VICE did a great expose on vehicle hacking.
New and more frequent application vulnerabilities
This idea is related to the next two items, but I decided to put this one first. We do not test enough, nor do we program securely. Yes, there are basic functions that we try to put into code, but far too often do I hear “our developers don’t know or understand security.” I am not saying that the development community is not concerned about security, but you only know what you know. And until we are able to test code for security, train our developers on security (constantly) and give enough time in a sprint to allow for security to review and test, we will continue to have exposures in our software.
More of the same – Lack of patching
Patching is and will still continue to be at the top of the list for IT and security departments for the foreseeable future. We still don’t have a firm handle on this issue both from an operational perspective, and from a company perspective. I am going to ask you: “if you’re in IT, are your personal devices patched? How many times do you click on ‘remind me tomorrow’ for updates?” Patching is and will be for the foreseeable future a weekly issue and concern.
Container and Container infrastructure
As developers strive for a smaller, more resilient application and process, the container market will continue to thrive and grow. But, when that happens and people share code openly, we will have exposures in application flaws. I think scenarios like this will play out – bad actor posts code to a popular “hub.” An unsuspecting developer downloads it and puts it to use. The bad actor starts to monitor the company that the developer works at for the flaw he developed. Access granted…
Room for growth
- Breach and Attack Simulation (BAS)
The idea that we need to continuously test our security and security architectures is paramount. I think as this space grows and acquires more funding and attention from the board room, we will be able to put things like AI and application security testing into these solutions. I feel that we are just scratching the surface on this domain.
- Application scanning
We need more intelligence and more flexibility in this market space. Not all applications are created equal and that is where the struggle is real. We need more accessibility for our development communities to be able to reveal flaws so they are able to fix or have the code fixed before an application is released into production.
- More in the way of automated security
Just like we have autofill for our personal information, we need to look at common security, what I call standard blocking and tackling, to be automated. A new security patch comes out? Great, it’s installed. A security configuration is missing or changed, nope – not for long. I equate poor security configuration to the seatbelt light or annoying noise in your car, if you don’t click it, it tells you until you do. Yes, it’s a manual task to click the seatbelt, but that annoying “ding” gets you to do it. We need that annoying ding to patch and securely configure our systems.
- Zero-trust model
I did not see zero-trust as a practical model right off the bat. Once I stopped to think about it, I relate this to my house. I have a zero-trust model in my everyday life and it doesn’t affect how I operate from day-to-day. Yes, I have to stop and greet someone and decide if I want to allow a person to know something about me or if I allow that person into my home. We need to do the same with our digital life. Zero-trust needs to be the de facto standard. If you don’t have a need for information, you don’t have access to it. And, we should be responsible for allowing access to it.