New Man-in-the-Disk attack leaves millions of Android phones vulnerable

man-in-the-disk android hacking apps


Security researchers at Check Point Software Technologies have discovered a new attack vector against the Android operating system that could potentially allow attackers to silently infect your smartphones with malicious apps or launch denial of service attacks.

Dubbed Man-in-the-Disk, the attack takes advantage of the way Android apps utilize ‘External Storage’ system to store app-related data, which if tampered could result in code injection in the privileged context of the targeted application.

Google itself offers guidelines to Android application developers urging them to use internal storage, which is an isolated space allocated to each application protected using Android’s built-in sandbox, to store their sensitive files or data.

However, researchers found that many popular apps—including Google Translate itself, along with Yandex Translate, Google Voice Typing, Google Text-to-Speech, Xiaomi Browser—were using unprotected external storage that can be accessed by any application installed on the same device.

How Android Man-in-the-Disk Attack Works?

Similar to the “man-in-the-middle” attack, the concept of “man-in-the-disk” (MitD) attack involves interception and manipulation of data being exchanged between external storage and an application, which if replaced with a carefully crafted derivative “would lead to harmful results.”

man-in-the-disk android hacking apps

For instance, researchers found that Xiaomi web browser downloads its latest version on the external storage of the device before installing the update. Since app fails to validate the integrity of the data, the app’s legitimate update code can be replaced with a malicious one.

“Xiaomi Browser was found to be using the External Storage as a staging resource for application updates,” the researchers said in a blog post.
“As a result, our team was able to carry out an attack by which the application’s update code was replaced, resulting in the installation of an alternative, undesired application instead of the legitimate update.”

In this way, attackers can get a man-in-the-disk position, from where they can monitor data transferred between any other app on the user’s smartphone and the external storage and overwrite it with their own malicious version in order to manipulate or crash them


The attack can also be abused to install another malicious app in the background without the user’s knowledge, which can eventually be used to escalate privileges and gain access to other parts of the Android device, like camera, microphone, contact list, and more.

Man-in-the-Disk Attack Video Demonstrations

Check Point researchers also managed to compromise files and crash Google Translate, Google Voice-to-Text, and Yandex Translate because those apps also failed to validate the integrity of data used from the Android’s external storage.




Among the apps that Check Point researchers tested for this new MitD attack were Google Translate, Yandex Translate, Google Voice Typing, LG Application Manager, LG World, Google Text-to-Speech, and Xiaomi Browser.

Google, which itself doesn’t follow its security guidelines, acknowledged and fixed some affected applications and is in the process of fixing other vulnerable apps as well, Check Point said.


Besides Google, the researchers also approached the developers of other vulnerable applications as well, but some, including, Xiaomi declined to fix the issue, according to the researchers.

“Upon discovery of these application vulnerabilities, we contacted Google, Xiaomi, and vendors of other vulnerable applications to update them and request their response,” Check Point researchers said.
“A fix to the applications of Google was released shortly after, additional vulnerable applications are being updated and will be disclosed once the patch is made available to their users, while Xiaomi chose not to address it at this time.”

The researchers stressed they only tested a small number of major applications and therefore expect the issue affects a more significant number of Android apps than what they explicitly noted, leaving millions of Android users potentially vulnerable to cyber threats.


via:  thehackernews


Save pagePDF pageEmail pagePrint page

Amazon Rapids, the chat fiction app for kids, is now free

amazon rapids

Amazon Rapids, the chat fiction that encourages kids to read by presenting stories in the form of text message conversations, is now going free. Previously, Amazon had been charging $2.99 per month for a subscription that allows unlimited access to its story collection, which now numbers in the hundreds.

First launched in November 2016, Amazon Rapids was meant to capitalize on kids’ interest in chat fiction apps like Hooked, Yarn, Tap and others, which tend to cater to a slightly older teenage crowd. Amazon Rapids, meanwhile, was the schoolager-appropriate version, without the swearing, alcohol, sex and yeah, even incest references you’ll find in the Hooked app, for example. (Yuck. Delete.)

Instead, Amazon Rapids’ stories are aimed at kids ages 5 to 12 and generally just silly and fun. They’re not meant to addict kids through the use of cliffhangers and timeouts, nor are they scary.

Some of the app’s stories also serve as crossovers that helped promote Amazon’s kids’ TV shows, like “Danger & Eggs,” and “Niko and the Sword of Light.” These were authored by the shows’ writers, allowing them to extend the show’s universe in a natural way.

In addition, the app included educational features like a built-in glossary and a read-along mode to help younger readers.

However, the app wasn’t heavily marketed by Amazon, and many parents don’t even know it exists, it seems.

According to data from Sensor Tower, Amazon Rapids has been installed only around 120,000+ times to date, three-quarters of which are on iOS. (Subscription revenue goes through Amazon, not the app stores, so the firm doesn’t have a figure for that.)

Amazon Rapids is ranked pretty low on the App Store, at No. 1105 for iPhone downloads in the Education category, and No. 1001 on iPad. The highest it ever reached was No. 65 on iPad.

Oddly, it chose not to compete in the “Books” category, where the other chat fiction apps reside, as do the other non-traditional “book” apps, like Wattpad’s crowd-sourced fiction app, Audible’s audiobooks app, various comics apps, and others.

Amazon now says that the hundreds of stories in Rapids will be free going forward. Families can also listen to some of these stories through the Storytime Alexa skill, launched last summer, which includes stories from Amazon Rapids, along with others.

Given Amazon Rapids’ small user base, it’s clear that Amazon no longer believes it makes sense to try to sell subscriptions, and likely now sees its database of stories as more of a value-add for Alexa owners.

That said, it’s unclear what this means for Rapids’ future development and story catalog, which may not continue to grow.

Update: Amazon tells us its immediate focus is not going to be on adding new content to Rapids, but on adapting its stories for the Amazon Storytime skill.

Monthly subscribers will no longer be charged and annual subscribers will be refunded for the remainder of the year. As a “thank you,” each customer will also receive a $5 promotional credit.


via:  techcrunch

Save pagePDF pageEmail pagePrint page

WhatsApp now allows group voice and video calls between up to 4 people

WhatsApp has added a much-requested new feature after it began to allow users to make group voice and video calls.

It’s been just over three years since the company, which is owned by Facebook, introduced voice calls and later a video option one year later. Today, WhatsApp counts over 1.5 billion monthly users and it says they make over two billion minutes of calls via its service each day.

Starting this week, callers can now add friends by hitting the “add participant” button which appears in the top right corner of their screen. The maximum number of participants is four and, impressively, WhatsApp said the calls are end-to-end encrypted.

That’s not an easy thing to do. Telegram, a self-professed secure messaging app, hasn’t even gotten around to encrypting its group messaging chats, let alone group calls.

On the encryption side, WhatsApp has long worked with WhisperSystems to cover all messages and calls on its platform from prying eyes and ears. That said, the relationship between the two become a little more complicated this year when WhatsApp co-founder Brian Acton donated $50 million of his wealth — accumulated from Facebook’s acquisition of his company in 2014 — to the Signal Foundation, which is associated with WhisperSystems.

Acton quit Facebook last year — this year he encouraged people to delete the social network for its data and privacy screw-ups — while his fellow WhatsApp co-founder Jan Koum joined him in departing in May of this year.

Like Acton, Koum was apparently irked by scandals such as Cambridge Analytica, although his on record explanation for quitting was to “do things I enjoy outside of technology, such as collecting rare air-cooled Porsches, working on my cars and playing ultimate frisbee.” Each to their own.


via:  techcrunch

Save pagePDF pageEmail pagePrint page

Flaw exposed Comcast Xfinity customers’ partial home addresses and SSNs

Poor security measures have reportedly put the personal details of Comcast Xfinity customers at risk, a researcher has revealed.

According to a BuzzFeed News report, security researcher Ryan Stevenson found a vulnerability in the high-speed ISP’s online customer portal that could allow unauthorised parties to determine the partial home address of customers.

The flaw was found in the “in-home authentication” webpage that customers could use to access their Comcast Xfinity bills without the hassle of logging in.

In-home authentication (also known as Home-Based Authentication, HBA, or IP authentication) is supposed to reduce the friction for customer attempting to access their accounts and reduce the number of password resets requested.

The webpage requested that users verified their accounts by choosing their correct home address from a displayed list of four partial home addresses.

Choose the correct address, and you gain access to the billing account.

How does Comcast Xfinity know which is your correct home address? By looking at the webpage visitor’s IP address.

But there lies the problem. Security researcher Ryan Stevenson was able to spoof a customer’s IP address and trick Comcast by changing the X-Forwarded-For header in their request.

Then, by repeatedly refreshing the login page, three of the suggested partial home addresses would change – and only one would stay the same, the correct one belonging to the targeted customer.

An attacker would now know the first digit of the customer’s street number and the first three letters of the street where they lived with asterisks hiding all other characters.

As BuzzFeed News explains, it would then be possible for a malicious hacker to determine the customer’s city, state, and postal code for the partial address by using an IP lookup website.

It’s easy to imagine how an individual might be targeted using the technique, as an IP address is shared with any website internet users access. If a malicious actor wanted to determine a particular XFinity customer’s home address, they might even simply send their target a link to a webpage under their control or embed a tracking pixel inside an HTML message with the specific intention of capturing an IP address.

But the story doesn’t end there, as Stevenson also found another security hole in Comcast Xfinity’s systems – specifically a sign-up for page for authorized dealers. The webpage was vulnerable to hackers attempting to brute force a customer’s Social Security Number.

A form on the page requested the customer’s home address to be entered (perhaps determined using the technique described above) along with the last four digits of the customer’s Social Security Number.

In a huge blunder, the webpage allowed an unlimited number of attempts to get the last four digits of the social security number correct – meaning an attacker could simply write some code to automatically cycle through all the possibilities from 0000 to 9999 until hitting gold.

Comcast responded to the report of the vulnerabilities from BuzzFeed News, patching quickly to avoid the security holes being exploited by others in the future:

“We quickly investigated these issues and within hours we blocked both vulnerabilities, eliminating the ability to conduct the actions described by these researchers. We take our customers’ security very seriously, and we have no reason to believe these vulnerabilities were ever used against Comcast customers outside of the research described in this report.”



via:  tripwire

Save pagePDF pageEmail pagePrint page

Many Developers Have Yet to Take Responsibility for Code Security, Reveals DevOps Study

A DevOps survey revealed that many developers have yet to take responsibility for the security of the code they produce.

According to Checkmarx’s report, “Managing Software Exposure: Time to Fully Embed Security into Your Application Lifecycle,” 93 percent of respondents said it’s either highly desirable or desirable that developers take responsibility for the security of the code they produce. But many developers aren’t living up to this ownership. Just 51 percent of respondents reported that their developers shoulder this duty. Forty-one percent of participants revealed this issue is addressed quite poorly or not at all at their organization.

Feeding this challenge could be a lack of training among developers on how to produce secure code. Nearly all (96 percent) respondents emphasized the importance of this training. But less than half said it’s being appropriately addressed at their workplace. Meanwhile, 49 percent of participants asserted that this training is not receiving the focus it deserves.

For its report, Checkmarx surveyed 183 individuals who hold IT, security and software development titles at organizations worldwide. Their responses help illustrate some of the challenges involved with injecting security into the DevOps cycle.

One of the obstacles uncovered in the study is the fact that software security is still overlooked by many boards. More than half (57 percent) of respondents said that software security now warrants a boardroom-level discussion. But 45 percent said it’s hard to get executives’ buy-in for this issue.

Another challenge revealed in the report is that developers and operations personnel are still struggling to make a cohesive DevOps culture. Seventy-two percent of survey participants said as much when they admitted that different teams within IT are still reluctant to trust one another.

It’s important that organizations consider all these issues of merging DevOps with security going forward. But Checkmarx has a recommendation for what should be a priority:

The reality is that in order to prevent potential software exposure throughout the software development lifecycle, we must first tackle the issue of ownership and responsibility, bringing together employees of diverse skill levels and backgrounds to help inspire more mutual trust and respect.



Via:   tripwire

Save pagePDF pageEmail pagePrint page

Security as a Quality Gate for DevOps

It’s hardly a controversial statement to say that DevOps is changing the way that organizations build and deploy applications. There’s plenty of material, stories, whitepapers and whole companies that demonstrate this trend. There are, however, a couple of things that make a discussion about security and DevOps important.

First, while there are a lot of organizations that have adopted DevOps tools and processes, there are many, many more that haven’t. That means that there are a lot of organizations that will do so in the future. And where there is adoption, it’s not necessarily comprehensive. It may be that one group has done so, or that teams are using some tools, but not others. In other words, DevOps is still fundamentally an early-stage technological movement.

The second reason is that DevOps is set to transform security, and no one is quite sure what that means, though there are a lot of opinions on the topic. Given that context, what should we be doing to secure this brave new world? We should start by looking at the pervasive industry problems. It’s tempting to start any DevSecOps discussion with technology. There’s a lot of it, and there’s always something new. But DevOps is really about solving a business problem, and so we should stay a level above the technology, at least for a bit.

Problem 1: Unacceptable Risk

A typical DevOps lifecycle involves pre-deployment testing, but rarely scanning for risks such as vulnerabilities, misconfigurations and compliance. It’s important to talk about risk broadly because all of these elements are real and can have a real impact on an organization. It’s tempting to focus on vulnerabilities, and it’s tempting to state that they all need to be fixed, but the reality is that ‘risk’ is broad and acceptance is organizationally specific. If risks aren’t caught prior to deployment of images to production, then unacceptable risks are also deployed.

Problem 2: Vulnerable Repositories

If you really think about it, every incident starts with some change. That change may, however, occur outside of your organization. Vulnerabilities are discovered all the time, and when a new vulnerability is published, an asset that you previously counted as acceptably secure might suddenly change state (though nothing on the asset itself has changed). Container repositories suffer from the same issue. If you’ve got a collection of images stored for use, even if you assessed them when they were added to that repository, they might become vulnerable over time.

Problem 3: Production Assessment is Too Late

A totally valid response to the first problem might be to apply the information security tools you have today to DevOps. These are tools that were largely developed to secure servers, workstations, laptops and network devices. Repurposing them for DevOps often results in questions like “can we put <security agent> in the running containers” and “can I scan the running containers for vulnerabilities.” These are patently bad ideas, but they are not sufficient, and perhaps more importantly, inefficient. Introducing security controls at the production end of the process, and then trying to address findings, is one way to create friction between DevOps and Security.

Driving Towards Solutions

It does no good to talk about problems without a discussion of the solutions. There are a number of requirements that apply here and it’s worthwhile to enumerate them.


This is clearly a core requirement for any solution to the problems discussed above. Assessment must be done prior to pushing containers to production in order to catch risk before it’s exploitable.


In order to be effective in a DevOps environment, the solution must integrate with the tools that developers are already using. That means that it can’t require additional manual steps on a build-by-build basis, or that the developer go to a different tool to get results. DevOps is about velocity, so creating friction needs to be avoided.


Recall the difference between ‘vulnerabilities’ and ‘risk’ that was discussed above? It’s vital that the assessment provided actually identifies the risks that matter to your organization. There’s not such thing as a ‘security scan.’ There are scans for more specific risks, like vulnerabilities, misconfigurations, compliance. Leaving risk out of the process means letting it into production.


DevOps doesn’t usually happen in one team or one place (logical or geographical). When I say ‘accessibility,’ I’m intending to describe the requirement that the technology and people who need access to the solution can do so without substantially changing how they do their job. Part of the answer here is likely SaaS, but also elasticity to deal with the requirements of your business.


Finally, risk is personal. A solution that finds all the bad things and then requires that you fix them in simply insufficient. As a team or organization, you need to define what level of risk you’re willing to tolerate, and then you need to be able to instantiate that as the quality gate in the solution.

DevOps really is poised to change the security landscape. While there are bound to be more problems to solve that we haven’t discovered yet, there’s real work to be done here today. It’s not an impossible task, but it does take awareness and effort.

To learn more, Tripwire is hosting a special webcast on August 21 titled “Leading a DevOps Transformation.

Join us and guest presenters to learn how to help your organization achieve higher levels of performance whilst ensuring security is a continuous aspect of the process.

You can register here or click on the image below!


via: tripwire

Save pagePDF pageEmail pagePrint page

DevOps and Cloud – The Match that Drives Today’s Businesses

When concepts like DevOps and Cloud computing come together, this powerful combination propels organizational growth at a rapid speed.

Some trends in today’s industry have helped bring about the collaboration of these two most important change agents. Let’s take a look at them here:

  1. The world is witnessing an industry-wide shift wherein we are transitioning from a product-based economy to a service-based economy.
  2. The 21st century business environment demands that companies focus on agility & innovation rather than stability and efficiency.
  3. The digital dimension has drastically begun to influence the physical dimension.

Most organizations today are beginning to realize the potential of these business transformation agents. While DevOps is a more process-oriented concept, the cloud acts as a catalyst to pace up this process.



Cloud computing complements DevOps in a way that its flexibility provisions experimentation in the DevOps process. The agility of cloud computing makes it an ideal partner to work with.

Operations-oriented companies use cloud-computing to pace up the development process and a developer’s productivity and efficiency at an individual level with cloud tools, application-specific infrastructure, and self-service catalogs.

With DevOps in the cloud, the two teams work together ,understanding each other’s language, with developers teaching operations about code, operations teaching developers about infrastructure, and security leading to a close-knitted circuit of similar thinking professionals.

The transformation from the product to service economy alongside data infusion has transformed software providers into customers who also use the services of the cloud to provision software-as-a-service (SAAS).

New-generation apps need complex technology stacks that require great effort for creation and configuration. And thanks to the cloud, these development functions are performed in a matter of minutes or hours unlike earlier times when development activity took weeks or months.


with many companies are falling prey to hacking, it is always crucial to implement security in the framework of your infrastructure.

And since DevOps and the cloud are the most utilized and most crucial platforms that drive business development, most IT professionals are incorporating security in these platforms.

DevOps professionals are embedding security as code (coming to be recognized as DevSecOps) into the DevOps framework so that future instances of security breaches are avoided, whereas in the cloud, most cloud providers equip their applications, tools, and mainly infrastructure with security measures giving customers the assurance of safe business operations. Even in the event of a security breach, options like business continuity and disaster recovery help you recover what matters the most.

  • The DevOps team should develop a self-service approach wherein professionals ensure that the speed with which the cloud delivers should not be affected by the continuation of traditional practices.
  • DevOps automation should not just be a workflow element but rather become a culture that encourages everyone to identify roadblocks and look to eliminate them.
  • And lastly, measure every process to ensure its desired outcome

DevOps is definitely a cultural transformation that is made better and achieved faster with assistance from the cloud but not without organizational support. Secondly, while It is always attractive for DevOps teams to work with the latest technology or opt for a cloud provider who offers the best price, organizations need to consider several factors within the organization to go ahead with its need for cloud adoption.

Lastly, it is not DevOps vs cloud but rather a DevOps-Cloud collaboration that drives the success of most 21st century business. DevOps tools may not be enough to meet the growing demands of a constantly changing market, but the cloud can be a wise solution for faster deployment of code and software development.

Also, Tripwire is hosting a special webcast on August 21 titled “Leading a DevOps Transformation“.

Join us and guest presenters to learn how to help your organization achieve higher levels of performance whilst ensuring security is a continuous aspect of the process.

You can register here or click on the image below!


via:   tripwire

Save pagePDF pageEmail pagePrint page

Determining Importance with Objective Vulnerability Scoring

The holiday season is upon us, and nearly every day, my wife asks me what I want for Christmas. As a pop culture geek with interests in most fandoms, I have dozens of items that I could ask for, but the ultimate question is what do I really want to ask her to spend money on.

In a perfect and very geeky world, I would likely come up with a method of measuring my interests, but in reality, I’m ultimately going to just pick an item near and dear to my heart. That’s because our choices in situations like this tend to be subjective.

While these types of determinations of importance should be subjective, we often see subjective vulnerability scoring that should be objective. Systems like High, Medium, Low, and 1-5 are not objective and provide minimal value when prioritizing risk in your environment.

There are better ways to prioritize risk.

The most famous example would be CVSS, a system which is available in every vulnerability management solution. With CVSSv2, we saw vendors take their own twists on the calculation, sometimes adding their own scoring levels. We also saw instances where scores were calculated differently based on personal opinion. CVSSv3 has improved upon this with stricter definitions, but score generation still manages to be subjective as some definitions are ignored and redefined. At this time, however, it is the most accurate and valuable publicly available scoring system.

The Tripwire IP360 Scoring System is as objective as they come and factors in all the criteria critical to your environment including vulnerability age, level of access, and ease of attack. It provides Tripwire IP360 users with a clearly defined prioritization that makes resolving vulnerabilities an objective process.

Should you require more for your environment, ASPL-Based Scoring allows customers to tweak the Tripwire IP360 scoring system while knowing that the foundation is still completely objective.

There are times when you need customization in your environment, but you should be allowed to determine where that customization occurs. If everyone else applies their own customizations (as seems to sometimes be the case with other popular scoring systems), it’s impossible to know if they make sense in your environment.

With ASPL-Based Scoring, Tripwire’s ASPL (content) packages contain our trusted, objective scoring while still allowing you the flexibility to know that critical issues in your environment are elevated with subtle tweaks to the Tripwire IP360 score of a specific vulnerability.

Don’t let your vulnerability management system provide you with a vulnerability prioritization similar to how you select a gift. Instead, rely on a scientific approach that gives clear, concise results every time.

Either way, use the vulnerability prioritization as a good way to prioritize your issues.


via:  tripwire

Save pagePDF pageEmail pagePrint page

Cisco is buying Duo Security for $2.35B in cash

Cisco announced its intention to buy Ann Arbor, MI-based security firm, Duo Security. Under the terms of the agreement, Cisco is paying $2.35 billion in cash and assumed equity awards for Duo.

Duo Security was founded in 2010 by Dug Song and Jonathan Oberheide and went on to raise $121.M through several rounds of funding. The company has 700 employees with offices throughout the United States and in London, though the company has remained headquartered in Ann Arbor.

Co-founder and CEO Dug Song will continue leading Duo as its General Manager and will join Cisco’s Networking and Security business led by EVP and GM David Goeckeler. Cisco in a statement said they value Michigan’s “resources, rich talent pool, and infrastructure,” and remain committed to Duo’s investment and presence in the Great Lakes State.

The acquisition feels like a good fit for Cisco. Duo’s security apparatus lets employees use their own device for adaptive authentication. Instead of issuing key fobs with security codes, Duo’s solution works securely with any device. And within Cisco’s environment, the technology should feel like a natural fit for CTOs looking for secure two-factor authentication.

“Our partnership is the product of the rapid evolution of the IT landscape alongside a modernizing workforce, which has completely changed how organizations must think about security,” said Dug Song, Duo Security’s co-founder and chief executive officer. “Cisco created the modern IT infrastructure, and together we will rapidly accelerate our mission of securing access for all users, with any device, connecting to any application, on any network. By joining forces with the world’s largest networking and enterprise security company, we have a unique opportunity to drive change at a massive scale, and reshape the industry.”

Over the last few years, Cisco has made several key acquisitions: OpenDNS, Sourcefire, Cloudlock, and now Duo. This latest deal is expected to close in the first quarter of Cisco’s fiscal year 2019.


via:  techcrunch

Save pagePDF pageEmail pagePrint page

The Five Stages of Vulnerability Management

A key to having a good information security program within your organization is having a good vulnerability management program. Most, if not all, regulatory policies and information security frameworks advise having a strong vulnerability management program as one of the first things an organization should do when building their information security program.

The Center for Internet Security specifically lists it as number three in the Top 20 CIS Controls.

Over the years, I’ve seen a variety of different vulnerability management programs and worked with many companies with various levels of maturation in their VM programs. This post will outline the five stages of maturity based on the Capability Maturity Model (CMM) and give you an idea as to how to take your organization the next level of maturity. To read the full whitepaper, check out this link.

What is the Capability Maturity Model?

The CMM is a model that helps develop and refine a process in an incremental and definable method.  More information on the model can be found here. The five stages of the CMM are:


Stage 1: Initial

In the Initial stage of a vulnerability management program, there are generally no or minimal processes and procedures. The vulnerability scans are done by a third-party vendor as part of a penetration test or part of an external scan. These scans are typically done from one to four times per year at the request of an auditor or a regulatory requirement.

The vendor who does the audit will provide a report of the vulnerabilities within the organization. The organization will then typically remediate any Critical or High risks to ensure that they remain compliant. The remaining information gets filed away once a passing grade has been given.

As we’ve seen over the course of the last couple of years, security cannot just be treated as a compliance checkbox. If you are still in this stage, you are a prime target for an attacker. It would be wise to begin maturing a program if you haven’t started already.

Stage 2: Managed

In the Managed stage of a vulnerability management program, the vulnerability scanning is brought in-house. The organization defines a set of procedures for vulnerability scanning. They would purchase a vulnerability management solution and begin to scan on a weekly or monthly basis. Unauthenticated vulnerability scans are run, and the security administrators begin to see vulnerabilities from an exterior perspective.

Most organizations I see in this stage do not have support from their upper management, leaving them with a limited budget. This results in purchasing a relatively cheap solution or using a free open-source vulnerability scanner. While the lower-end solutions do provide a basic scan, they are limited in the reliability of their data collection, business context and automation.

Using a lower-end solution could prove to be problematic in a couple of different ways. The first is in the accuracy and prioritization of your vulnerability reporting. If you begin to send reports to your system administrators with a bunch of false positives, you will immediately lose their trust. They, like everyone else these days, are very busy and want to make sure they are maximizing their time effectively. A reliable and accurate report is critical to ensuring that remediation can occur in a timely manner.

The second problem is that even if you verify that the vulnerabilities are in fact vulnerable, how do you prioritize which ones they should fix first? Most solutions offer a High, Medium, Low or a 1-10 score. With the limited resources system administrators have, they realistically can only fix a few vulnerabilities at a time. How do they know which 10 is their most 10 or which High is the most High? Without appropriate prioritization, this can be a daunting task. Granted, an industry standard such as CVSS is warranted for a common communication mechanism. Being able to prioritize in addition to this provides tremendous value.

Stage 3: Defined

In the Defined stage of a vulnerability management program, the processes and procedures are well-characterized and are understood throughout the organization. The information security team has support from their executive management as well as trust from the system administrators.

At this point, the information security team has proven that the vulnerability management solution they chose is reliable and safe for scanning on the organization’s network. As recommended by the Center for Internet Security, authenticated vulnerability scans are run on a, at minimum, weekly basis with audience-specific reports being delivered to various levels in the organization. The system administrators receive specific vulnerability reports, while management receives vulnerability risk trending reports.

Vulnerability management state data is shared with the rest of the information security ecosystem to provide actionable intelligence for the information security team.  For example, if an exploit is detected on the external firewall, a quick correlation can be run in the Security Incident and Event Management (SIEM) tool to identify which systems are vulnerable to that exploit.

The majority of organizations I’ve seen are somewhere between the Managed and the Defined stage. As I noted above, a very common problem is gaining the trust of the system administrators. If the solution that was initially chosen did not meet the requirements of the organization, it can be very difficult to regain their trust.

Stage 4: Quantitatively Managed

In the Quantitatively Managed stage of a vulnerability management program, the specific attributes of the program are quantifiable, and metrics are provided to the management team. The following are some vulnerability metrics that every organization should be tracking:

  • What is the percentage of the organization’s business systems that have not recently been scanned by the organization’s vulnerability management system?
  • What is the average vulnerability score of each of the organization’s business systems?
  • What is the total vulnerability score of each of the organization’s business systems?
  • How long does it take, on average, to completely deploy operating system software updates to a business system?
  • How long does it take, on average, to completely deploy application software updates to a business system?

These metrics can be viewed holistically as an organization or broken down by the various business units to see which business units are reducing their risk and which are lagging behind.

Stage 5: Optimizing

In the Optimizing stage of a vulnerability management program, the metrics defined in the previous stage are targeted for improvement. Optimizing each of the metrics will ensure that the vulnerability management program continuously reduces the attack surface of the organization. The Information Security team should work with the management team to set attainable targets for the vulnerability management program. Once those targets are met consistently, new and more aggressive targets can be set with the goal of continuous process improvement.

Vulnerability management, combined with asset discovery, cover the top three of the Top 20 of the CIS Controls. Ensuring the ongoing maturation of your vulnerability management program is a key to reducing the attack surface of your organization. If we can each reduce the surface the attackers have to work with, we can make this world more secure, one network at a time!


via:  tripwire

Save pagePDF pageEmail pagePrint page