Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Operations

6/20/2018
10:00 AM
Kelly Sheridan
Kelly Sheridan
Slideshows
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail

The Best and Worst Tasks for Security Automation

As with all new tech, there are good times and and bad times to use it. Security experts share which tasks to prioritize for automation.
1 of 7

(Image: Zapp2Photo via Shutterstock)

(Image: Zapp2Photo via Shutterstock)

1 of 7
Comment  | 
Print  | 
Comments
Newest First  |  Oldest First  |  Threaded View
EdwardThirlwall
50%
50%
EdwardThirlwall,
User Rank: Moderator
7/16/2018 | 3:33:18 AM
Re: Don't Automate: Penetration Testing (this is where I disagree)
To ensure that we indeed have a good security automation setup put in place, it is best to follow these guidelines from the experts. We can never be too sure when it comes to security and it definitely would not pay should there be breaches in the future just because of a failure to keep up with the system. We need to be on our guard at all times even if we have a good system already implemented. It does not pay to be extra careful than to pay the price when problems arise in the future.
RetiredUser
50%
50%
RetiredUser,
User Rank: Ninja
7/8/2018 | 9:53:21 PM
Re: Don't Automate: Penetration Testing (this is where I disagree)
"I think you missed this point in the overall online discussion. I do do believe that human intervention is needed but at some point, the synergistic nature of machine and man will help improve the overall process. You are still tied into in how things done now, what I am referencing is making a paradigm shift (this will take time and effort on both parts) to create an environment where we teach the machine to learn and address daily everyday issues (the prcoess is in its infancy stages, where there is a question about how to proceed, then the human should update or provide instructions as to how we need to handle the issue)." 

OK, I'm on the same page as you now, Todd.  I'm still not sure we can ever get there, but I'd love to see some of your energy make its way into a white paper!  I believe there is a need for humans in the pen-testing life-cycle that can never, and I mean never, be replaced by automation.  A lot of your ideas as to what can someday be taken over by automation don't jive for me but I love to see attempts at it, nonetheless.  I have a certain belief in the place AI and machine learning have in tech, and certain areas of "hacking" as we humans know it is a human exercise.  Anything AI and machine learning accomplishes in terms of pen-testing is not going to be the same; humans will continue to do it better, and do it in ways that predictive models and "intelligent" machines can't model.  My uneducated opinion only, straight from the trenches.       
tdsan
50%
50%
tdsan,
User Rank: Ninja
7/8/2018 | 7:38:06 PM
Re: Don't Automate: Penetration Testing (this is where I disagree)
In addition, if it was a false positive, it would be up to us to update the process so to address the anomaly in a more efficient manner (the end-user could identify if this was an anomaly that needed to be reviewed expeditiously or if the methods of remediation were correct).

I think you missed this point in the overall online discussion. I do do believe that human intervention is needed but at some point, the synergistic nature of machine and man will help improve the overall process. You are still tied into in how things done now, what I am referencing is making a paradigm shift (this will take time and effort on both parts) to create an environment where we teach the machine to learn and address daily everyday issues (the prcoess is in its infancy stages, where there is a question about how to proceed, then the human should update or provide instructions as to how we need to handle the issue). So there is teaching that needs to take place, we need to look into the future and stop relying soley on current methods (again it is going to take time), because the methods we are using are not working across the board or at least by what I have found (when a group wants something bad enough, there is nothing we can do to stop is, it is invetible). There is and should be a better way.

In addition, all the steps you listed below, that can be automated. Just like I listed the steps for thwarting a potential attack, why can't the machine do it (again, I am not saying now), but in the near future. The machine should baseline the environment, identify normal processing levels (there are times in which there will need to be intervention) but if it can identify something that is considered an anomaly, report on that anomaly, identify the systems or applications that are being affected (even if it is a zero-day, test a possible solution in its isolated environment, then provide that solution to the end-user, that would pay huge dividends (because the machine has learned and created a baselined map of the environment), then it would be easy to identify an attack because something new has been introduced to your environment, the same way the body identifies a problem, it communicates with all endpoints (nerves) and reports back to centralized center (brain), then sentries (white blood cells) are sent to analyze the problem, hence the term neural network.

T
RetiredUser
50%
50%
RetiredUser,
User Rank: Ninja
7/8/2018 | 3:36:02 AM
Re: Don't Automate: Penetration Testing (this is where I disagree)
While I appreciate your argument for why to automate pen-testing, Todd, I do have to say that it must still be partnered with manual pen-testing expertise. There is sometimes a perception of a computer humming away while a variety of automated intrusion functions poke at an app or website held by folks who either haven't done the grunt work, or are looking for a reason to let go of the labor associated with it. However, a good example why manual pen-testing will always be needed is 0-day vulnerabilities. While you could potentially have an automated pen-testing system that is tied in to the many 0-day databases out there and monitors for new vulnerabilities, the level of sophistication and adaptive AI required to write new code and attempt exploiting these 0-days is at a level few companies could afford in a software package, let alone an automation company afford to develop for its automated pen-testing suite. You are talking Fortune 500 and military grade software at a minimum and even with today's tech, such a system is still not going to be seen generally available and operating at a level of tolerable faults for some time.


I feel much of what you note as the benefits of going with automation for pen-testing are either an approach for design for a future system, or current benefits of pen-testing in areas of low-change intrusion, such as taking the results of manual pen-testing and building an automation suite to test in areas that are actually not changing such that new code would need to be written, or some level of human analysis and creative thinking is required. You could almost see this as a sort of regression test suite where once the flaw is identified in one code base, you automate testing against future code bases to validate the flaw is closed, or you turn the tests on other similar code bases you expect have the flaw to demonstrate it. It's hard for automated software to tests resolutions when it first has to read and understand a 0-day report, write code to test the attack, then write code to test a resolution, or patch, to fix the flaw.

     

 
tdsan
50%
50%
tdsan,
User Rank: Ninja
7/7/2018 | 4:16:40 PM
Don't Automate: Penetration Testing (this is where I disagree)
Pen Testing should be automated because the purpose of a PenTest is to identify the vulnerability and to make it known to the end-user so some proactive measure can be taken or done (remediation). The problem I have with the comment is that everyone is aware that there is no silver-bullet to address all of the areas of security, but I do think automation would help to reduce the threat matrix because systems would start learning from one another. Yes, I do believe that human intervention is needed (only in certain cases, one-offs) to be part of the process but this can be improved overtime where the machine understands that certain processes we kick off are not intended to cause harm, this is the learning process. As noted, machines will miss certain things but that is where the learning comes into play along with system updates. Remember, we (humans & machine) will miss somethings but by creating a mature model where systems can learning in cyber-security arena, we can reduce the number of false-positives to a minimum.

To address Boyce's or the moderator's concern, we have something called "Continuous Monitoring" or SIEM where an ongoing analysis of the various sessions and potential threats are steadily being monitored. The problem is what happens when that person gets tired or is not at the office (late night, a skeleton crew is not as talented as the group that is there during the day). There needs to be some intelligence in the decision-making process where the threats are prioritized based on their level of priority. In addition, the system needs to be able to adjust (sliding scale) on the fly where if there are threats that are not as nefarious as the prior or post threat, then the system needs to be able to adjust that sliding scale and move that threat up the ladder of discernment and priority. Then from that classification, the system needs to be able to pull data from external sources where potential resolutions could be matched against the potential threat. Finally, the system needs to be associated with a percentage based on the level of accuracy to resolve the issue (100%, 80%, 70% resolution scale) where the system is able to learn based on recreating the vulnerability in a virtual mock environment.

The solution could be validated in seconds by the machine learning process (whereby the system actually learns how to mitigate the problem based on external repositories or tactics it has learned on its on by breaking down, analyzing, resolving and then reporting on the threat that it found to be an anomaly in the scheme of things (i.e. a legitimate file was written to by a variant where the variant injected code into the registry, kernel or system file, the system was able to identify what was written to the file and remove the code that was written to the file or replaces the system file with a baseline file that was validated as having the correct MD5 checksum), this would be perceived as a win-win for all parties involved (except for the actor who was trying to access the environment in the first place).

It would take a human, days to figure out the type of attack, what was changed, what was affected, the remediation techniques and report on the incident where the machine could take minutes or seconds to do (there will be some tweaking but not only could we reduce the number of possible security vulerabilities but system crashes and application failures as well).

If we were able to reduce both then the attack vectors and threat landscape, this would improve the overall process 4 fold because the machines would be able to point out the contention, identify the resolution, test the resolution, implement the resolution and report on the solution, this would prove extremely beneficial to allow the end-user to concentrate on other tasks. In addition, if it was a false positive, it would be up to us to update the process so to address the anomaly in a more efficient manner (the end-user could identify if this was an anomaly that needed to be reviewed expeditiously or if the methods of remediation were correct). This process could be shared by other machines where the machines learn from one another. Moreover, we could also develop a process where machines provided health information - Security or functional processing levels - then we could improve every aspect of the computing process.

Todd
Data Privacy Protections for the Most Vulnerable -- Children
Dimitri Sirota, Founder & CEO of BigID,  10/17/2019
Sodinokibi Ransomware: Where Attackers' Money Goes
Kelly Sheridan, Staff Editor, Dark Reading,  10/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-18216
PUBLISHED: 2019-10-20
** DISPUTED ** The BIOS configuration design on ASUS ROG Zephyrus M GM501GS laptops with BIOS 313 relies on the main battery instead of using a CMOS battery, which reduces the value of a protection mechanism in which booting from a USB device is prohibited. Attackers who have physical laptop access ...
CVE-2019-18214
PUBLISHED: 2019-10-19
The Video_Converter app 0.1.0 for Nextcloud allows denial of service (CPU and memory consumption) via multiple concurrent conversions because many FFmpeg processes may be running at once. (The workload is not queued for serial execution.)
CVE-2019-18202
PUBLISHED: 2019-10-19
Information Disclosure is possible on WAGO Series PFC100 and PFC200 devices before FW12 due to improper access control. A remote attacker can check for the existence of paths and file names via crafted HTTP requests.
CVE-2019-18209
PUBLISHED: 2019-10-19
templates/pad.html in Etherpad-Lite 1.7.5 has XSS when the browser does not encode the path of the URL, as demonstrated by Internet Explorer.
CVE-2019-18198
PUBLISHED: 2019-10-18
In the Linux kernel before 5.3.4, a reference count usage error in the fib6_rule_suppress() function in the fib6 suppression feature of net/ipv6/fib6_rules.c, when handling the FIB_LOOKUP_NOREF flag, can be exploited by a local attacker to corrupt memory, aka CID-ca7a03c41753.