Daily Archives: February 24, 2017

Linda Musthaler is a Principal Analyst with Essential Solutions Corp., which offers consulting services to computer industry and corporate clients to help define and fulfill the potential of IT.

This column is available in a weekly newsletter called IT Best Practices. Click here to subscribe.

During my recent trip to Tel Aviv to attend CyberTech 2017, I had a one-on-one conversation with Barak Klinghofer, co-founder and chief product officer of Hexadite. He gave me a preview of an educational presentation he was to give two weeks later at the RSA Conference. His insight is worth repeating for anyone looking to add automation tools to their security toolset.

As I saw at CyberTech, and Im sure was the case at RSA, the hottest topics were security automation, automated incident response and security orchestration. These can be confusing terms, as every vendor describes them a little bit differently.

In this article, Klinghofer gives his definition of security automation and an overview of several hot market trends today. Klinghofer and the other Hexadite co-founders all worked as security analysts before they started their company, so they have walked in the shoes of the people who are most likely to use security automation tools.

Klinghofer defines security automation as an active process of the following:

1. Mimicking the ideal steps a human would take to investigate a cyber threat. The tool should not just assist or provide more insight or more data about a threat, but really mimic the same steps and the logic an analyst should take when doing a cyber investigation. If you can train people to do an investigation, you can probably codify the logic in a system.

2. Determining whether the threat requires action. This goes beyond running something in a sandbox or comparing it to a threat intelligence list, to include using the results of those kinds of tests and really questioning the evidence. A SOC analyst would do this, so its reasonable to expect a security automation tool to do this as well.

3. Performing the necessary remediation actions. This isnt as easy as it sounds because there are so many configuration permutations and ramifications for possible actions taken. You want to know that your automation solution is aware of as many use cases as possible because you are expecting the same result as you would get from a human analyst.

4. Deciding what additional investigations should be next. Many security automation tools stop after the first three steps, but a SOC analyst would go a step further and try to verify or validate that the threat was removed and is no longer a risk to the organization. For example, if there is an alert about a phishing instance, who else in the organization might have that same phish sitting in his inbox?

The big trend in the cybersecurity market is security orchestration. Most of these types of tools are API-driven as opposed to logic-driven, and the basic premise is to get different types of security tools to work together to drive a process. To get value from orchestration, you really need to define the outcome you are expecting.

Orchestration is the means to an end; its not the goal itself. If you can find use cases where connecting two devices or solutions gives you extra value that you couldnt get from either of the devices or solutions alone, then orchestration is worthwhile. That said, there are several types of tools that say they are doing orchestration or automation.

One example is workflow tools. Vendors say these tools will enhance alert data and automate the information sent to your SOC analyst to streamline your incident response (IR) communications. What they actually mean is they will provide you with a framework to better organize your teams IR flow with built-in ticketing, playbooks and user rules. What you get is something that will tell your IR staff what they should do and in what order, if they have the time to do it. Plus, everything will be documented.

Suppose one of your end-users received a phish. The workflow tool receives the phishing alert from the detection system and starts the process. First the tool will collect the data on the different entities within the email to get more context.The tool will scan and analyze the URLs within the email, and if there is an attachment, it will run it in a sandbox and try to find all of the threat intel. Next the tool will open and assign a ticket which includes the enriched data to assist in the manual investigation. The analyst will take over with a manual process to deep dive into the alert, but there might be additional steps the workflow tool can help facilitate. The main objective of the tool is to speed up the process and keep it moving along, especially if multiple people are involved.

Another type of security automation tool does threat prioritization. Vendors say they will enhance the alert data and prioritize the information sent to your security analysts to streamline your incident response process. This way you wont need to analyze everything. What they actually mean is they will ignore everything that is under a specified threshold.

Prioritization is essentially a conscious decision about what you are willing to let go without investigationbut you are never 100% sure that you can ignore something. Its hard to determine if something is a legitimate risk or not without investigating it. Many breaches have occurred when alerts were not investigated. The advantage of prioritization is that your SOC analysts arent overwhelmed with too much to do.

Scripting tools are another type of security automation tool. Vendors say they will provide a way to enhance your IR by integrating your SecOps solutions in order to get a good result. What you really get is an open development framework with some of the APIs already pre-built, but eventually you need to build the playbooks you want. It will take you longer to do this and you need to have experts who know exactly what they are doing. Defining, building and testing the use cases can be very complicated. While the scenarios might sound easy, the fact is that there are many complications and the scripts wont work in all situations. Basically you end up trading security analysts for programmers.

Klinghofer says Hexadites security orchestration and automation tool, Automated Incident Response Solution (AIRS), investigates every alert. AIRS receives alerts from multiple detection and endpoint security systems, adds contextual intelligence and then automatically launches an investigation.

He says the system analyzes data from the network and endpoint devices using algorithms and tools to determine whether the alert is a false alarm, low-level threat, or security breach. Based on pre-defined policies and best practices codified in the logic of the solution, AIRS applies targeted mitigation efforts to stop the full extent of the breach. It follows the same processes and logic that SOC analysts would follow, but without human intervention. (See Hexadite's Automated Incident Response Solution narrows the gap between detection and response.)

With an increasing number of security threats being detected, and the growing shortage of security analysts, most enterprises will be looking for some sort of security automation tool to improve their IR capabilities. If your company is in the market for such a tool, be sure you understand just what it will do for you.

More here:

How to assess security automation tools - Network World

Linux Foundation Creates New Platform for Network Automation Wall Street Journal (subscription) (blog) The Linux Foundation said Thursday that it had created a new platform for automating the management of communications networks, a labor-intensive process that is widely viewed as a bottleneck in the the world of corporate information technology. The ...

Go here to see the original:

Linux Foundation Creates New Platform for Network Automation - Wall Street Journal (subscription) (blog)

Scott Davisis EVP of Engineering & Chief Technology Officer for Embotics.

With the explosive growth of cloud and SaaS-based business applications and services, the underlying software architectures used to construct these applications are changing dramatically. Microservices architecture is not a brand new trend but has been picking up momentum as the preferred architecture for constructing cloud native applications. Microservices provide ways tobreak apart large monolithic applications into sets of small, discrete components that facilitate independent development and operational scaling. Key to this architecture is making sure that each microservice handles one and only one function with a well defined API. Microservices must also have no dependencies on each other except for their APIs.

When mixed with automation as a dynamic management solution for the individual application components, applications become less limited by the infrastructure they run on. Through automation and infrastructure as code technologies, applications now have the ability to control their underlying infrastructure technologies, turning them into services to be harnessed on demand and programmatically during application execution. While weve seen cloud native pioneers such as Uber, Netflix, Ebay, and Twitter publicly embrace this method of building and delivering their services, many organizations arent sure where to begin when it comes to achieving effective and efficient operations through this app architecture revolution.

Before microservices, it would take engineers months or years to build and maintain large monolithic applications, but today microservices design methodology makes it easier to develop systems with reusable components that can be utilized by multiple applications and services throughout the organization, saving developers valuable time. This enables better continuous delivery, as small units are easier for developers to manage, test and deploy.

In order to successfully deliver microservices and container solutions cost-effectively and at scale, its important to have a proper design framework in mind. Microservices must have a well formed, backward and forward compatible API and only communicate with its peers through their API. Each Microservice should perform one and only one dedicated function. Each microservice is ideally stateless and if needed typically has its own dedicated persistent state that is not exposed to others. When all of these principles are rigorously followed, each microservice can be deployed and scaled independently because they do not require information about the internal implementation of any other services all that is required is that they have well-defined APIs.

At the same time, microservices are well matched to and driving the adoption of container technologies as the two often work in conjunction. Each microservice has to run somewhere, and containers are often the preferred choice because they are self-contained, rapidly provisioned or cloned, and usually stateless. Developers can easily construct a container with all the required code to execute the microservice, allowing them to break a problem into smaller pieces, which was not previously possible at this scale. Containers offer developers a way to package their function into this self-contained block of code, creating efficient, isolated and decoupled execution engines for each app and service.

The problem? This creates more component parts that need to be dynamically managed to achieve their promise of scalable, cost-effective cloud services. Automation can provide the dynamic management needed to deliver microservices and container solutions cost effectively and at scale. With microservices-based designs, developers and operations staff are left with many more component parts that need to grow and shrink independently. Automation can be harnessed to reduce this complexity and deliver the desired results.

Microservices-based designs fundamentally enable faster development and deployment of highly scalable applications, whether for the cloud or on-premise. Flexible automation via both portals and APIs is the key ingredient for effectively deploying and managing these next generation, distributed applications, across todays multi-cloud environments.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Penton.

View post:

The App Architecture Revolution: Microservices, Containers and Automation - Data Center Knowledge

Image: iStock/VectorStory

In software development, the rise of automation tools has largely eliminated human involvement. ON one hand, it's easy to say that automation has further eliminated the need for QA but that's not the case. As experts have noted, QA is still essential, as is human intervention in some cases, to ensure a quality product is deployed.

"Test automation may largely eliminate the need for manual testing in some scenarios, but it will never eliminate the need for QA," said Chris Marsh, director of technology for AKQA. Test automation will be a part of QA engineers' toolboxes and will help focus testing efforts, he added, noting that unit tests are cheap to produce and run and therefore the most likely to be automated. Integration and UI tests, however, may be subject to more manual intervention.

The problem with traditional approaches like this is in trying to eliminate all defects before launching new software, which can prevent feedback from actual users as well as reducing ROI. No piece of software is truly defect-free, according to Marsh. QA engineers need to be involved in the build pipeline and consult on quality across the entire project lifecycle, he added.

Testing is as only as good as the test

Automation does make some aspects of QA easier, but if the test itself isn't up to snuff, it won't provide the desired result, according to Greg Hoffer, VP of engineering at Globalscape. "Because technology development is a complex, dynamic process, automated QA...is doomed to fail unless someone is able to make sure that the tests are current, or new bugs and vulnerabilities will not be detected," he said, citing the case of a serious security bug in the CryptKeeper app that wasn't found during the QA process.

Additionally, fully automated QA may result in perfectly accurate yet completely unusable software that doesn't meet any business needs, Hoffer said. Any automation in DevOps needs to be validated for usability to meet the needs of humans.

"Automated QA, continuous integration (CI), and continuous deployment (CD) are all great advances in the efficiency of DevOps. But we should not expect them to be perfect. It is still incumbent on the developer community to be vigilant," he said.

QA may actually become more important

As a result of automation, more QA work will move to the front end of the software development lifecycle, and CI tools will become more important for testing, according to Rupinder Singh, senior vice president, expert services at Software AG. "As confidence in CI and automation increases, there is a very likely scenario of customers using Continuous Delivery for selective parts of their applications, although it still is not something that is completely reliable," he said. However, the QA role may become more important in technical communities as automation takes over manual test cycles, Singh noted.

QA automated tests can prove whether known paths still work or identify new features or code that might have introduced issues, said Mark Doyle, software architect at Collabroscape. "However, it still takes ... human creativity and ingenuity to explore those paths, and then write automated tests against expected outputs," he said. "Companies must - and should - continue to employee QA teams, and they need to invest in training and software licenses for the automation platforms, but the benefit is still there."

More stable software systems is one such benefit, according to Doyle. First, running an automated test can validate the build to save time and energy on the QA personnel side before testing. Secondly, if the failed tests automatically entered issues into a defect tracking system, QA is able to come up with more comprehensive test plans, he said.

Ultimately, automation isn't a bad thing - it saves time and helps focus efforts on more human-intensive processes while removing the low-hanging fruit. It makes QA testing easier for routine tests. But it does need to be taken with a grain of salt to ensure that accurate, useless software isn't being deployed.

Also see: 80% of IoT apps not tested for vulnerabilities, report says 3 ways to prevent your app developers from blowing off QA testingHow to use scrum for app development QA testingHow to build a solid workflow for updating mobile apps

Follow this link:

Why automation doesn't necessarily remove the need for QA - TechRepublic