Last updated at Mon, 24 Jul 2017 15:50:59 GMT

Welcome to the brand new Federal Friday Blog here on Security Street! I tend to be an avid consumer of industry information, trends and general points of information within the InfoSec space. I want to use this blog to aggregate some of the information I find helpful and share that info with all of you on a weekly basis.

Additionally we will be publishing federally-focused content from many of the great resources we have here at Rapid7. This content will highlight trends within the space and how to best utilize our products within the scope of these topics. At the end of last month, our Product Manager for Nexpose, Ryan Poppa, published the first of these blog posts around vulnerabilities associated with IAVA. We will have similar content coming out from our folks on the Metasploit and Mobilisafe teams as well so stay tuned! In the meantime here are a few topics I've seen trending this week.

BYOD and Mobile Security continue to be a hot topic across all business sectors and with the recent DISA approval of Apple iPhones and iPads running iOS6, we can see that starting to ramp up within the federal space as well. Even though this isn't a true BYOD environment within the DoD, yet, the adoption of iOS6 powered devices in conjunction with The Samsung Galaxy and BlackBerry Z10 & Q10 is a clear sign that we're heading to a more mobile federal work force. While the DoD is very restrictive of the devices on their network, the same isn't always true within the different Federal Departments or Service Integrators, and this highlights the importance of starting to think long term regarding how mobile will affect your environment. The longer organizations delay addressing the inevitable reality of a fully mobile workforce the more reactive, rather than proactive, the approach to securing this growing segment will be. That's why it's so imperative to turn these internal discussions into actionable BYOD/Mobile Security strategies.

While BYOD/Mobile Security still has a lot of grey area around it, most everyone can agree that there are some pretty serious risks involved with these devices. Whether action can be taken now within your organization is heavily dependent on budget and resources as this can add additional costs in terms of tools as well as personnel. That being said, the worst thing an organization can do is ignore the coming storm. Building mobile risk into your security road map gives you the ability to be flexible with its prioritization, especially as your employees become more accustomed to utilizing their mobile devices in conjunction with their daily routines.  This includes both personal and work-related activities. The mobile workforce will ramp up much faster in some segments/organizations than others, but regardless of the timing within your organization, this will need to be addressed sooner rather than later to ensure that your infrastructure defenses, and the personnel responsible for guarding the network, won't be caught off guard. There have been a number of articles on this topic recently, and I found these two pretty interesting if you want to read more on the topic:

You might also want to check out our free on demand webcast on establishing a mobile security policy for your organization: Establishing Your Company's Mobile Security Policy

As couple of articles around Security Automation also caught my attention this week. The thought here is that increasing automation within security tools will free up a good chunk of bandwidth for most security teams; a lot of the current manual processes can run on a set schedule, without the need for anyone to manually kick-off a scan or report. This frees up time for security professionals to focus on other activities. For example, being able to quickly discover active vulnerabilities and network intrusions on an ongoing, automated basis, would hopefully enable security teams to have more bandwidth for more proactive activities. However, this can be a tricky subject within any organization, let alone within the federal space; where budget can sometimes dictate the active tool set.. The problem with all of this is that when you try to integrate these different pieces within the existing security architecture, there can be significant communication issues between tools from varying vendors. That hope of freed up time disappears into countless reporting errors and additional time needed to manually edit or run some of the scans or reports. Understanding which tools that you currently use, and their ability to integrate well with your other tools, as well as which tools don't integrate well, will help avoid some of the headaches (and hours) spent trying to get these products to work together. This is increasingly valuable as the effectiveness and availability of automation within existing products gain traction within the market.

Hopefully the work that NIST and DHS are currently undertaking to standardize the federal security environment through the Security Content Automation Protocol (SCAP) and the Einstein Program (which currently has its third iteration in production) will help with this. By setting up standards by which vendors must abide, the communication between multiple tools should improve, thus improving the effectiveness of the teams tasked to monitor and secure their environments. Reaching out to, and working with, your current vendors to get more in line with automation is a step you can take to see which tools are already optimized with this option.  We have a number of automation features in our solutions, for example for vulnerability scanning in Nexpose, or social engineering campaigns in Metasploit.  If you want to know more about any of the features, please email If you're looking for more on automation, you may also find this article from GCN helpful: