“When we’re looking at taking a containerized workload, one of the challenges with it is you lose a lot of the visibility when you’re running at scale in a virtualized environment,” said Robbie Jerrom (@robbiej), member of the Global Cloud Native Apps SME Team for VMware, after his presentation, Your DevOps Transformation. Culture, Technology, or Both? at Vmworld 2015 in San Francisco.

When those containers are in a VMware environment you can actually see their behavior from an operations perspective. You can see their resources. And from a security perspective, you get two and three layers of protection from the rest of the containers and operations, added Jerrom.

Jerrom gave his presentation with Ed Hoppitt, a CTO ambassador with VMware who stressed that DevOps is not about a technological change. It’s about culture and fear.

“Change drives fear and change can breed suspicion,” said Hoppitt who also recommended you run away from anyone who says they can give you more agility if you purchase $2 million in tools.

DevOps is simply operations and developers working together across the end-to-end service lifecycle, from design through the development to live production. It requires a shift in an IT mindset, added Hoppitt who pointed out that market forces are leading the need for DevOps change.

Software is changing everything

• Competition was known; now it's unpredictable.
• Assets were owned; now they're shared.
• Innovation was methodical planning; now it’s rapid iteration.
• App development used to be slow; now it's instant.
• Organizations used to be built to last; now they're built to change.
• Customers have gone from the millions to billions.

Because our demands for what software can and should do are changing so rapidly, so is our need to evolve development to meet those demands. Hence the rising interest in DevOps.

Jerrom indicated several ways DevOps has evolved traditional development:

What is DevOps?

• DevOps extends agile development or creates agile++.
• An agile ops team member is a VM / OS specialist, not just an app developer.
• Agile ops staff are automation specialists, not just UI developers.
• Continuous delivery has now become continuous deployment.
• You essentially skip the manual step of handing an application over to operations.
• You go from code to testing where it's almost at production.
• Code is never “done.” The new done is always in development.

DevOps is really about a team that can create something that's useful to the business, said Jerrom. The full stack is having full appreciation of infrastructure, security, and all the code. It's also about the person who can talk and communicate this across all departments. As an individual, the “full stack” developer does not exist. The full stack is the team.

VMware can bridge the two worlds, as virtual machines and container isolation can operate better together, said Jerrom.

• Containers offer OS level isolation rather than just hardware isolation from VMs.
• Containers focus on environmental consistency; VMs focus on security and multi-tenancy.

The developer lifecycle and a production stack can all be handled by VMware Cloud-Native Apps Stack.

If you wrap containers into virtual machines you can solve the DevOps problem and get around the cycle of data, application development, and analysis, said Jerrom. Those who succeed are the ones who can get around this loop the fastest. 

All CISOs should track metrics to support their security programs. Security metrics are crucial to decision making, budgets and executive reporting. But what should be tracked besides the total number of vulnerabilities and remediations? Scott Hollis recommends two key metrics to start with, and discusses the need for contextual information in Using Security Metrics to Drive Action.

This article appears as part of Tenable’s Level-up Your IT Security BrandPost initiative hosted by CIO.com this month.

Read the full article

Practicing preventive measures is just as important for security as it is for personal health. Identifying weaknesses and building strength should be your MO when building a security program for your organization.

In a recent article on Dark Reading, Get Fit: Remove Security Weaknesses, Ted Gary draws analogies between personal health and fitness programs to information security, illustrating his point that creating good cyber hygiene involves building core strength, monitoring for problems, and acting on warning signs. Ted also recommends Tenable’s upcoming webinar, 10 Weaknesses Your Adversaries Know About, but You Don’t, for more details and discussions.

This article appears on behalf of Tenable Network Security as part of a Partner Perspectives initiative that Dark Reading is hosting this month.

Read the full article

Most modern organizations support separate IT, security and business divisions, driven by their own departmental goals, objectives, and priorities. With so much at stake, how do you get IT, Development Operations (DevOps), and security teams working together to assure compliance and business security? Scott Hollis shares his thoughts on this challenge in Aligning Operations: IT – Business - Security.

Scott’s article appears as part of Tenable’s Level-up Your IT Security BrandPost initiative hosted by CIO.com this month.

Read the full article

At Black Hat 2015, one of the people I interviewed said the best way we can be smarter about security is to learn from the people who are already smart in security. It’s wise advice and that's why I attended the Infrastructure Security Panel Discussion at VMworld 2015 in San Francisco.

The panel was moderated by Mike Foley (@mikefoley), senior technical marketing manager, VMware, and included panelists:

• Greg Hatch, infrastructure architect, Raymond James
• Steve Kaplan, principal infrastructure architect, Defense Contract Management Agency
• Davi Ottenheimer (@daviottenheimer), president, flyingpenguin

It was a really interesting discussion on the security issues that many aren’t considering. There were also references to some of the themes of VMworld — that stuff should just work, and that there’s a great need to remove complexity from people’s lives.

I was most intrigued by the following four issues brought up by Ottenheimer, so I asked him to expand them on camera.

Temporary vanishing databases: Can you build a data environment that vanishes after a certain period of time? This would be valuable for disaster recovery if you need to move information to a location temporarily, or to improve performance of an application. If certain data doesn’t need to be persistent, why let it sit around and languish and bring down the performance of the rest of your application?

Authentication should be focused on knowledge: We don’t just authenticate people by their names. We look at them and gather other clues, such as what they look like, the way they walk, talk, who their friends are, etc. For that reason, we should realize that our simple methods of online authentication are far from sufficient, and we should integrate approaches from the way we handle authentication in the real world.

Don’t just ask for a solution. Know the problem: Knowing about problems is important. Don't shut down that discussion by saying, “Don’t tell me the problem. Just fix it.” The real goal is to move away from binary understanding of security issues. Begin looking at analytics so you can have a more nuanced understanding and discussion.

Classifying data creates a new vulnerability: The more metadata you get the more knowledge you have, and that makes it hard to create privacy. Be wary of trying to come up with a schema to determine your most sensitive data. The act of creating metadata can create new vulnerabilities.

Here are some of the other interesting items that came up in the security panel discussion:

• In the financial industry, we don't trust the cloud with our client list and customer data. We are slowly moving towards IaaS.
• The biggest challenge is determining when you’ve been hacked when the hacker is able to get in with valid credentials.
• Do you have a way to monitor all the tools that you have? Do you have the people, and can you have them operational 24 hours a day? Criminals don’t work 9-to-5.
• Lean teams of just two or three hope that they're doing security right. The answer to being better at security is to do and think about it a lot, even if you’re just a small team.
• IT can't provide secure stuff fast enough to the business guys, so the business guys often get what they want themselves. When IT fails this way, it gives rise to shadow IT, or the business procuring tech services themselves. If you’re heading down that path, look at the APIs for SaaS applications. They’re pretty good because they allow you to do an audit and to see who is using these outside applications.
• Most SaaS applications can deliver the security you want, but they don't necessarily have it turned on by default.
• SaaS applications don’t give a satisfactory answer to the question of "can you wipe out all the data completely?" Some won't even let you have access.
• It's important to have all of IT very transparent for users so that they can provision it easily. It's a simple process of letting a request come in and an action be taken. In general, the goal is to drive better IT behavior.
• Everyone wants two-factor authentication on vSphere. Everyone wants it. You just need to yell at the product managers and you'll get it. That's how things often get done. When the customers demand it, it gets done.
• How do you educate the C-suite that they need to think of security beyond compliance? If you go into one of these discussions, they start to glass over. Get into a security discussion by talking about how you’re trying to fix process problems, not necessarily security. Talk about how you can improve the business and the lifecycle of the product. You're just rebranding the classic security discussion.
• If you don't get what you want, you could pull the Fear, Uncertainty, and Doubt (FUD) card. That will help you get what you want. But that only gets you so far.

“Think about an M&M. Once you’re in that M&M, you kind of get wherever you want. With the data center it’s similar. Virtual desktop is in, and now you have free run of the place,” said Aaron Dumbrow (@adumbrow), senior systems engineer, VMware in his Austin Powers-infused presentation "Your Laptop Has Been Stolen with 80,000 Patient Records - You're Held to Ransom for… ONE MILLION DOLLARS!" during VMworld 2015 in San Francisco.

A single firewall perimeter-based security solution is no longer sufficient. One step to a more secure solution that isn’t just hard on the outside and gooey in the center is creating a micro-segmented data center where you can have unlimited firewalls at different points. The danger of creating policies for what you can and cannot do, is what you may have missed and rules sprawl. Too many rules becomes unusable or a miserable experience for the end user.

To understand what rules you should create, Dumbrow advises that you first understand the problem you’re trying to solve, then he offers the solution of software defined security. Given that he works in healthcare, he skews the discussion to healthcare related issues, but you can extrapolate to almost any other industry.

What is the problem we're trying to solve?

• Lost/stolen laptops: First step is to be able to secure it. Next step is to know what’s actually on that machine. Certain industry regulations levy heavy fines if you don’t know what’s on a computer that’s been lost/stolen.
• BYOD: Managing devices owned by a person and the company.
• Remote/temporary workers: Support this audience, and applications being built by contractors.
• Patients demand a consumer experience: If it doesn't just ‘work’ they're not going to use it. Why can't it work like this consumer product we love so much?
• Affordable Care Act requirements: There are so many in there that the healthcare industry is still struggling to understand what they all mean. They have to comply with the law and protect patients. How do you provide care while maintaining compliance?

Software defined security solution

• Data center micro-segmentation: You have to have data center security before you can have end user computer security.
• Isolate: Don’t allow a communication path between unrelated networks.
• Segment: Control the communication path within a single network. This is where you can create fine-grained enforcement of security. Security policies can be based on logical groupings of VMs.
• Advanced services: Depending on policies, include third party security programs.

Putting a firewall on the desktop can be as granular as you'd like it to be, said Dumbrow. This is all done by a policy. But as we discussed in our conversation, this is an ongoing battle to manage all the issues of security, usability, and industry compliance. While they’re not ready to let policies be automatically changed through credential authorization (“We don’t want doctors spinning up servers,” said Dumbrow), they can make the process as simple as possible. When a request comes in for access, policy changes can be managed by a low-level employee, thus minimizing the workflow disruption for the end user.

Recent analyst predictions are anticipating significant increases in the amount of corporate data bypassing perimeter security and flowing between mobile devices and the cloud. In the new IT landscape, which endpoints are most vulnerable? Which devices and applications need more security? How does the security department reach out and protect new SaaS environments and BYOD?

Diane Garey discusses these issues in Identifying Vulnerable Entry Points. This article is part of the BrandPost series, Level-up Your IT Security, a Tenable initiative hosted by CIO.com.

Read the full article

With the proliferation of cloud, mobility and BYOD, endpoint protection is front and center in security departments these days. Focusing on threat detection is important, but eliminating weaknesses that provoke the attacks is also critical in the endpoint battle. In a recent article on Dark Reading, Why is Endpoint Security Failing? Manish Patel provides advice on security strategies that can strengthen your endpoint program as well as your overall security posture.

This article appears on behalf of Tenable Network Security as part of a Partner Perspectives initiative that Dark Reading is hosting this month.

Read the full article

CISOs are busier than ever answering questions from executives and senior management about the latest breaches and their own security programs. With the average tenure of a CISO trending around 17 months, how do they balance activities to actually ensure security while also keeping the company informed about their security posture? Scott Hollis tackles this dilemma in The Average CISO Tenure is 17 Months—Don’t be a Statistic!

This article appears as part of Tenable’s Level-up Your IT Security BrandPost initiative hosted by CIO.com this month.

Read the full article

Buying expensive and sophisticated security technology is a real challenge. Vendors will advise you on technology that is best suited for a particular situation, but they are also just trying to sell product. Before you sign on the dotted line, you need to ask the right questions to make sure you don’t end up with shelfware – underutilized technology. In a recent article on Dark Reading, Buyer Beware: How To Avoid Getting Sucked Into Shelfware, Gavin Millard presents three key questions that every vendor should address to make sure you get the most value from your investment.

This article appears on behalf of Tenable Network Security as part of a Partner Perspectives initiative that Dark Reading is hosting this month.

Read the full article

Businesses are not stagnant, and expansion can create growing pains for IT infrastructures. More IT assets and more potential vulnerabilities can strain your vulnerability management program.

Just how scalable is your vulnerability management solution? In Is Your Vulnerability Management Scalable?, Steve Hall presents key questions to ask vendors to determine the robustness and scalability of their vulnerability management solutions. Steve also recommends Tenable’s e-book on 10 Steps to Effective Vulnerability Management for more information.

This article appears on behalf of Tenable Network Security as part of a BrandPost initiative that CIO.com is hosting this month.

Read the full article

Security teams often lack accurate knowledge of assets on their networks. In particular, ignorance about laptops, BYODs, services, and SaaS applications can pose significant security risks. Unmanaged patching and noncompliant configurations present weaknesses that can spell trouble for your network. In a recent article on Dark Reading, Three Steps to Knowing Your Network, Ted Gary recommends several security frameworks for creating a robust asset discovery program and he prescribes three steps towards good cyber health.

This article appears on behalf of Tenable Network Security as part of a Partner Perspectives initiative that Dark Reading is hosting this month.

Read the full article

When shopping for a cloud-based vulnerability management (VM) solution, not all cloud environments are equal. While cost savings are a big draw, several significant features can help you achieve the maximum benefits from your vendor’s solution. In Putting the Cloud to Work in Vulnerability Management, Diane Garey summarizes the advantages of a cloud-based VM solution and enumerates the most important features that you should look for. She also points to a very relevant webcast with Paul Asadoorian and Jack Daniel from Tenable, and John Kindervag from Forrester Research.

This article appears on behalf of Tenable Network Security as part of a BrandPost initiative that CIO.com is hosting this month.

Read the full article

In Getting Started With Security Metrics, Marcus Ranum contends that metrics are the language of business, the primary means of communicating your security posture to executives. Metrics must tell a story and be relevant to your specific business. When asked, “What are the top metrics that I should keep?” Marcus provides an answer that may very well surprise you.

This article appears on behalf of Tenable Network Security as part of a BrandPost initiative that CIO.com is hosting this month.

Read the full article

There has been a lot of press coverage concerning the discovery of the XcodeGhost malware that affects iOS 9 and other Apple systems. This infection has caused 400 apps to be pulled from the Apple App Store so far. The malware was created by compromised compilers, where when an author codes an app, the final step between programming and the finished app is to compile it. These compromised compilers then inject hostile code into the unsuspecting author’s app. The unaware author then uploads the compiled app to a distribution store for download (in this case it was the Apple App Store, but it could have just as easily been any other “store” or software distribution point).

How could this have happened?

As is often the case, the primary questions I am hearing are “How can we detect it?” and “How can we clean it up?” But there is also the unusual question of “How could this have happened?” It’s this last question that I would like to address first.

All distribution stores have basic security checks to look for backdoors and malicious applications. Anyone submitting an app, either for initial distribution or updating existing applications, must go through this process. This software was designed in a way to bypass those security checks, as well as hide itself from the original app author. Even when and if the author submitted original source code to the people monitoring the store, there would be no indicator of the malware in the original source code. The only way to have determined modification would be to take the app from the store, reverse engineer it, and then compare that code to the original source code. This is not practical, as many programmers do not have the skill set or the tools to do a proper reverse engineering, and there are just too many apps for any given store to employ resources to do that job.

Protection

Further, since many of the affected devices are mobile devices, we face other issues. Mobile devices—generally Android and Apple—all run each app in its own “sandbox” which includes security software. Apple has built in rudimentary per-app permissions (i.e., turn off access to chat and camera, but not the contacts list for the app) that future versions of the Android OS will also include. But many people do not make full use of these security checks, and security apps can’t break out of their sandboxes to enforce it, although some do scan for and notify of “insecure” and “excessive permissions” apps that they can identify. In future versions of Nessus®, you will be able to audit for applications that may have been infected by XcodeGhost.

As mobile devices operate on their own data networks, we as users and corporate security officers cannot scan or monitor those channels. That leaves us one option: when a device connects to our WiFi, we can scan for and detect abnormal network traffic. Utilities such as Tenable’s SecurityCenter™ have this type of function to do just that. As it has been said many times, we often look at the top 10 or 20 security issues, because by addressing those, we solve 80% of our overall problems. However, by taking the time to look at the bottom of that list, which are the abnormalities that often get lost in the noise, patterns begin to emerge, and those patterns can be leveraged to identify an issue before it balloons into a major incident.

Trust in whitelists

In the case of XcodeGhost, what happened is one of the weaknesses of a whitelist. There is little the authors could have done to validate that their code wasn’t compromised, and the whitelist provider performed industry best practices, so now we have to update those practices based on real threats. Whitelists are trusted distribution points and need to remain trustworthy, as do their contributors. When someone compromises that chain of trust, it compromises the entire system. We as security professionals must add that to our risk analysis equations and remember to watch for the little things that can betray bigger intents.

For many of us in the information security industry, the vulnerability disclosure debate is old and tired. I’ve been dealing with this myself going on twenty years now. The underlying debate hasn’t changed much, but there have been a few new wrinkles and nuances added over the years. At its core, the debate is about how someone who finds a security vulnerability and the vendor of the product in which it was found should behave.

One of the big differences with this age-old debate today is that there are now new players in the game, players who were not around twenty, ten, or even five years ago; people who don't remember the days of full or no disclosure, the RFPolicy or the introduction of responsible disclosure that has morphed into coordinated disclosure. Companies such as auto manufacturers, airlines, energy companies and medical device manufacturers are just now starting to learn some of the painful lessons the rest of us learned the hard way. So we can either grit our teeth and flail about as these new entrants to the debate learn these old lessons, or we can attempt to gently guide them along the path that the rest of us have been trotting along for years and come to some sort of common level of understanding.

In fact, how to handle information security vulnerability information was one of the topics discussed at The White House Summit of Cyber Security and Consumer Protection back in February. This age old debate has become so important that even the President of the United States is discussing it.

Enter the National Telecommunications and Information Administration

The National Telecommunications and Information Administration (NTIA) under the Department of Commerce is attempting to advance the debate one more step. The NTIA has begun holding multi-stakeholder meetings in an attempt to come to some sort of consensus as to what should be the preferred course of action when a vulnerability is found. The first such meeting was recently held at the Berkeley School of Law in California. The NTIA has stressed that they are present only as a facilitator and have no desire to direct or influence the conversation at all and that it is up to the participants to decide what the output of the group will be.

Is the problem disclosure or bad code?

We need to work out the acceptable actions now, actions that we can all agree on, about what we will do with vulnerabilities when they get found.

The problem of what to do with security vulnerability information is not going to go away, in fact it is going to get worse—a lot worse. Actually, disclosure itself is not the problem. Disclosure is a symptom, a symptom of bad code. If you write code you are going to make mistakes. In fact, it is estimated that there are at least ten defects in every one thousand lines of code. The amount of code that companies are pushing into their products is growing at an ever increasing rate. Take cars for example: most modern vehicles rolling off the assembly line today contain over one million lines of software code. Based on industry averages, that means there is about ten thousand defects in every car. Not all of those defects are security problems, but some of them will be. As we continue to push software into vehicles, medical devices, refrigerators, light bulbs, etc. this problem will get worse and worse. We need to work out the acceptable actions now, actions that we can all agree on, about what we will do with vulnerabilities when they get found.

What should we do?

Of course, one option is to do nothing and maintain the status quo, meaning that researchers and vendors will continue to butt heads. Researchers will threaten full disclosure and vendors will run to their lawyers and the public will be caught in the middle. However, if we (the vendors and researchers) fail to take action and don’t come to some sort of agreement, we will likely find action being taken for us in the form of government regulation. We have a collective interest and a shared fate in the outcome of this issue; we should work on a solution together or we risk having a solution forced on us.

Let’s face it, there is a power inequity in the vulnerability equation. Vendors usually have money and lawyers, and it is easy for them to run to the courts to immediately stop threats to their bottom line. The researcher seldom has the resources available to match those of the vendor and is left at a disadvantage. And the public, who stands to gain the most from the information that the researcher has found, is diffuse and does not understand the complexities of the equation.

There has already been some criticism of the multi-stakeholder meetings held by the NTIA from people who rightly point out that the Department of Commerce has no way to enforce any outcome from these meetings. The have no enforcement arm, can not pass laws or levy fines. The process is also long and time consuming, with monthly meetings most likely being held over the next several years before any output can be released.

The NTIA contribution

What the NTIA can do—what they have already proven they can do—is get a disparate group of people in the same room to start the discussion and drive change.

What the NTIA can do—what they have already proven they can do—is get a disparate group of people in the same room to start the discussion and drive change. At the first meeting in Berkeley, the attendees proved to be varied and diverse, with viewpoints presented not only from security researchers but also large software vendors, vehicle manufacturers and medical device companies. That is the power that the NTIA can bring; by getting all of these people in the same room to discuss this important topic, maybe—just maybe—we can come to some sort of conclusion on this ancient debate.

Granted, the NTIA doesn’t have any enforcement authority, but that doesn’t mean we should just give up and walk away. It does not mean that we should shrug our shoulders and say that nothing will change. It does not mean that all the debate and discussion is just there so that people in the information security industry can listen to themselves talk. The more we sit down in the same room and discuss the problem, the more likely we will find a solution.

The status quo will not change without a revolution.

While many organizations focus on their vulnerability management programs to find critical vulnerabilities like the highly-publicized Shellshock, Poodle and Ghost, it’s equally important to validate system build and configuration change management processes, as these activities can also leave your systems and data at risk. Kelly Prevett and I addressed this topic last week in a Tenable webcast where we shared some interesting misconfiguration examples, discussed how to coordinate people, processes and technology to avoid misconfigurations, and explained how Nessus configuration audits can help.

How can system misconfigurations leave you vulnerable?

A good example is last year's data breach at MBIA. MBIA is the largest bond insurer in the USA, with reported assets of more than $16 billion in 2014. Last year, MBIA was in the news because of a data breach reportedly caused by a misconfigured Oracle Reports database server. This database server, part of mbiaweb.com was misconfigured so that instead of only sending data to authorized administrators, data was made public, picked up by the search engine crawlers and made available to anyone with a web browser. Account information like account numbers and balances was exposed. As soon as they were notified, MBIA shut down the server and notified their customers, but because of a misconfiguration, sensitive data was exposed for some time. Brian Krebs did a nice write up if you want to read more.

It’s not just misconfigurations that can leave you vulnerable. Not changing the default configuration can be equally risky.

It’s not just misconfigurations that can leave you vulnerable. Not changing the default configuration can be equally risky. Earlier this year, Swiss Security Firm BinaryEdge did a study where they scanned the Internet on various ports looking for servers running Redis, MongoDB, Memcache and ElasticSearch. They picked these applications because if you read the documentation, it’s clear these applications are not intended to be secure with default settings only. For example, the Redis website clearly states:

Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.

So, despite clear warning, it is obvious from the BinaryEdge study that not everyone reads the documentation. BinaryEdge received responses from hundreds of thousands of servers, delivering more than a terabyte of data. Misconfigurations can come in many forms.

Avoiding misconfigurations

Kelly walked through five steps to help ensure your systems and applications are configured appropriately, so you don’t end up in a situation like the above examples.

1. First, define the technical standard your organization will follow. Your organization might choose to follow a well-known industry benchmark like CIS or another best practice, or develop your own best practice. Involve more than just the security team in this decision (especially systems administrators) and don’t expect that all your systems will meet the standard on day one. It’s better to pick a future date and work towards compliance with that standard by that date.
2. Next, define roles and responsibilities. Ideally, there’s an executive champion responsible for getting a technical standard to sponsor the program and stakeholders from teams throughout the organization.
3. Document at what frequency assessments must be performed. Depending on the standard you choose, that standard might have a minimum designated interval for doing assessments. More frequent assessments will give you better visibility into whether systems are compliant with your standard or not.
4. Cite exception procedure for systems that do not comply with the technical standard. There will be systems that you may not be able to configure per your standard for a variety of reasons.
5. Finally, cite the scope (production, pre-production, certain business functions, vendors, etc.).

Kelly also shared good advice on the importance of continually measuring how this process is working for your organizations. Set realistic milestones and know that it may take your organization some period of time to meet them.

Configuration auditing in Nessus

Configuration auditing in Nessus, while perhaps not as well-known as its vulnerability scanning capability, is a core tenet of the Nessus solution.

While people and process play a big part in a configuration management program, technology can help too. Configuration auditing in Nessus®, while perhaps not as well-known as its vulnerability scanning capability, is a core tenet of the Nessus solution. Today there are more than 450 different configuration audit policies available for Nessus, ranging from CIS and DISA STIG audits for assets like applications, systems and databases, configuration audits to address standards like CERT and HIPAA, and even audit policies that look for sensitive content within Windows and Unix/Linux systems.

More frequent audits can result in greater visibility into configurations in your IT environment.

In the webcast, we talked about how to do configuration audits with Nessus; that you can either set up a configuration audit scan to run agent-less (ad hoc or scheduled) or use Nessus Agents. One of several benefits we discussed about using agents is that, since agents use local resources on the host where they’re installed, they can be a better way to more frequently run configuration audits without placing an undue performance load on your network. More frequent audits can result in greater visibility into configurations in your IT environment.

Resources

To learn more about configuration auditing in Nessus, check out these resources:

• Watch the recording of our Systems Misconfigurations Leave your Data at Risk webcast
• Sign up for our October 22, 2015 Nessus Agents Online Demo
• See Configuration Audit examples
• Follow the blog articles by our Director of Compliance Research, Mehul Revankar, who writes frequently about new configuration audit policies

Selecting a good vulnerability management solution is a balancing act. You need to consider a whole history of vulnerabilities, emerging technologies, and evolving attack vectors. How can you best protect your organization while covering all bases?

In What Distinguishes Vulnerability Management Solutions? Scott Hollis provides tips on selecting a vulnerability management solution. He discusses the need to make sure your vulnerability management solution is balanced and comprehensive, covering older CVEs as well as new technologies.

This article appears on behalf of Tenable Network Security as part of a BrandPost initiative that CIO.com is hosting this month.

Read the full article

In the past, many organizations avoided cloud-based applications simply because they felt that the cloud was less secure than their own facilities. But today, more and more companies are turning to the cloud for security solutions. What is driving the change? Should you consider moving to a cloud-based security solution? Listen to Cris Thomas, Strategist at Tenable Network Security (aka Space Rogue), as he discusses this change and its implications.

Many IT professionals think that moving applications to the cloud is an opportunity to save money. While the cloud may or may not save you money and provide efficiencies, what the cloud really offers is the opportunity to analyze and redesign your IT operations. Listen to Marcus Ranum, Tenable’s Senior Strategist, as he develops these ideas and provides advice on planning for cloud deployments.