Lets quickly define what I mean by “IT asset.” An asset can be any computer, server, network device, application, database, archive of uncompiled code, or whatever that has monetary or perceived value to the business. It’s easy to justify why a piece of hardware or software is an asset, as there is a direct cost involved with procurement, management, and maintenance. You also depreciate your hardware investments in your accounting books, so even those with the checkbooks are acutely aware of hardware costs and value. The not-so-obvious items are web applications and databases. Some disagree that a database is an “asset” but what if that database contains your entire customer list? Isn’t that important to the business? Essentially, if your IT department spends time working on, fixing, installing, or maintaining it as a part of their day-to-day duties, it’s probably an asset.

There are some very basic questions you should be able to answer with a high level of precision about your assets and, if you can’t, IT assets aren’t being managed properly in your organization.

Let me give you an example:

• How many physical servers do you have?
• How many laptops does the business own?
• When were assets purchased?
• How many servers are physical vs. virtual?
• What operating systems are your systems running (and what are their patch levels)?
• What MAC addresses are assigned to each system?
• Who owns each server? How do you get ahold of them? Who is the second point of contact if they’re not available?
• How many web applications do you have?
• How many licenses of Microsoft Office do you have?
• What is your total annual maintenance commitment for software?
• What is the circuit ID of your main Internet connection and what is the best number to call in case of an outage? (You don’t want to have to look through years of bills to try and identify this when your business is down.)

You should be able to answer all of those questions pretty quickly by looking at an IT asset management database. You don’t have to spend millions on the shiniest box with the prettiest light array. You can do an adequate job with a spreadsheet, SharePoint, and/or a home-grown application.

Here are some items you may find useful to track:

• AssetID
• Asset type: circuit, server, desktop, laptop, router, switch, web application, standalone application, database, SAN head, NAS head, disk shelf, firewall, bridge, thin WAP, thick WAP, wifi controller, other.
• Purchased from?
• Sales contact name
• Sales contact number
• Sales contact email
• Purchase date
• Purchase order number
• Purpose
• Physical location (Minneapolis, 511, rack 12, position 13-15)
• Unit cost
• Maintenance cost
• Deploy date
• Retirement date / lifecycle information
• Data classification
• Server classification
• Circuit ID
• Emergency contact name
• Emergency contact number
• Emergency contact email
• Service Level Agreement (SLA)
• Make
• Model
• PSU (single, dual, n+1, n+2, other)
• CPU
• Memory
• IP addresses associated
• Hostnames
• MAC addresses
• Operating system (very specific)
• Virtual/physical
• Physical host ID (another AssetID if virtual)
• Has virtual guests? (is a virtual host)
• Owner & contact info
• Secondary owner & contact info
• Upstream dependencies
• Downstream dependencies
• Hardware change history
• Software change history
• Failure history
• Patch history
• Notes

This is not exhaustive. It’s just meant to help organizations get an idea of where to start. The more specific and detailed your asset management database, the more sound the rest of your decisions will be when implementing and enforcing specific company policies. I also like a single database with version control for everything, so you only have a single location where you can find the answers you need. How you normalize your data is up to you, but I prefer a single table for everything. Obviously, if you have tens of millions of assets, this may not be reasonable.

From here you should also consider defining:

• How your organization is going to perform asset discovery;
• How you plan to capture the data to populate the database;
• How you plan to keep it up-to-date and verify the integrity of the data;
• Acceptable use of assets;
• Your organization’s official IT asset lifecycle for each major type of asset; and
• Data and server classification policies.

There are a ton of other policies you probably need to define here as well, but this discussion could quickly fill a library.

Get started today! You’ll find that this isn’t an easy project to get started with but, the sooner you get started and the more effort you put into the process, the easier things will get over time. If you need standards to lean on, have a look at section A.8 of the ISO/IEC 27001:2013 standard, and section 8 of the ISO/IEC 27002:2013 standard. ISO/IEC 27005 in section 8.2.2 helps identify assets your business should include in its risk assessment. PCI DSS version 3.0, requirement 2.4 requires “maintain an inventory of system components that are in scope for PCI.” Cataloging only PCI systems doesn’t seem to fulfill the spirit of the requirement, so I think it’s safe to say PCI requires IT asset management. Additionally requirement 12.2 states, “implement a risk-assessment that Identifies critical assets, threats, and vulnerabilities, and results in a formal risk assessment.” Risk assessments are not possible without first identifying the assets you need to protect. Consider management of all IT assets as a shadow requirement of becoming PCI compliant.

The post IT Asset Management – Where to Start appeared first on NetSPI.

So how does this relate to security, you ask? One of the dumb problems in the security industry is that there isn’t a standard way to disclose vulnerabilities to vendors or to network operators. Unless you have some sort of existing relationship with the company, or they go above and beyond in terms of security responsiveness (which is almost nobody), you start pitching your vulnerability disclosure into various e-mail boxes, snailmail letters, voicemail boxes, etc. More times than not, the information doesn’t make it to the right person, so you end up disclosing. When the bad press happens to catch someone’s attention, they get upset because you didn’t tell them about the problem first. It’s a lose-lose situation for everyone involved.

My suggestion is to resurrect good internet stewardship, and start standardizing on the SECURITY@domain.tld for vulnerability and security disclosure. The above RFC was written in 1997 and includes this mailbox under section 4 “NETWORK OPERATIONS MAILBOX NAMES,” so at least there is existing precedent for this naming convention. I suggest we expand the scope a little and use that mailbox for any security related topic. This can include, but is not limited to:

• Vulnerabilities on a website
• Vulnerabilities in software distributed by that company
• Vulnerabilities in services offered by the company
• Vulnerabilities on a public facing network or system that is maintained by that company
• Publicly leaked information on a websites like pastebin
• Sensitive documents blowing in the parking lot

What you do with the mailbox is up to you, but here are some ideas:

• Have an employee check this box once in a while, and manually distribute the messages to those that need the information.
• Create a secondary mailbox in Exchange that people can attach to and have your infosec department manage the mailbox.
• Create a distribution group or mailing list with key members of your organization subscribed.
• Have a ticketing system monitor the mailbox and create cases or tickets automagically when something comes in.

While we’re talking about standardizing vulnerability disclosure, lets put together some high-level process objectives we could all strive to attain:

1. All messages received on SECURITY@domain.tld should send an auto-reply back to the user immediately thanking them for their submission, and include a URL to a page with more information about that company’s vulnerability process. (We could even standardize the URL, how about something like www.domain.tld/security/?)
2. Within no more than 7 calendar days, the vendor MUST send a response back to the vulnerability submitter. The response should contain a case or ticket number they can reference in the future and a means of communication to check up on the status of the vulnerability. This gives the vendor an opportunity to accept the vulnerability as legitimate and issue a case or ticket number, and drop all other spam messages without assigning case numbers to bogus requests or spam messages. If no ticket number is issued within 72 hours for any reason at all, the submitter is free to disclose publically. If the submission is granted a ticket number, a three-month gag order and moratorium starts. The submitter should be reasonable and grant more time if the vendor gives a valid reason. For example, if the vulnerability were so widespread that a vendor would have to rewrite the entire application from the ground up, 3 months wouldn’t be enough time.
3. Once 3 months (or whatever the agreed upon time frame) is up, the vulnerability submitter is free to speak, blog, tweet about the vulnerability as they see fit. Once the gag timer expires, the submitter’s responsibility is terminated.

I realize this is a lofty idea that will get ignored, but I can dream. Thoughts, comments, and ideas on this are all greatly appreciated. Have you implemented something similar in your organization? Let me know in the comments how it worked for you.

UPDATE: since the release of this blog, a couple new standards have been released. ISO 24197, and ISO 30111 have been released for public consumption. I’ve not read either of these standards, but they should be reviewed by organizations when writing their vulnerability disclosure and handling policies.

The post Vulnerability Disclosure Submission Standard? appeared first on NetSPI.

Regular review of firewall configurations and how they’re deployed is considered a best practice and really helps promote good configuration from the simple act of looking at it from time to time. If best practice isn’t enough reason, regulatory requirements such as PCI require you to perform regular firewall configuration reviews (Requirement 1.1.6).  The firewall isn’t a black box that you setup and walk away from. Many times, this is the heart of your critical network, and to continue smooth operations, it requires maintenance. Improper segmentation and rule set configuration are also likely one of the core reasons you failed your most recent penetration tests, but this is often lost on a lot of people. Sure the initial access vector was MS08-067 on a test server, but why was someone from the user segment able to talk directly to the test network in the first place? Take my word for it, periodic configuration reviews are very important, regardless of the technology.

Unless you’re intimately familiar with firewall technologies, performing a useful review of a firewall is quite difficult. Many businesses don’t have the luxury of a dedicated firewall configuration employee or team.

There are a lot expensive tools that will look at your configuration and give you some rule set and configuration recommendations, but those require capex and opex budget allotments as well as the expertise to get the most out of the tools to maximize your investment. Unless you’ve mastered the basics, buying a tool isn’t going to be a good use of limited information security budget dollars. If you don’t want a tool, there are a plethora of clumsily put together checklists that attempt to help you solve this problem. However, even the better checklists seem to be a response to regulation and ignore best practice and availability items.

So what is my brilliant revelation, you ask? Well, I’ve created a checklist of course! Before you run to the wood shed and grab the pitchfork, take a look at what I have. My checklist isn’t specific to a product, platform, or regulation. This should be a good general checklist that you can use in any environment and the risky items should become self-evident as you work through the checklist.

Here are the goods:

• Firewall checklist (short) – short and to the point – for use on a regular basis. Use one form per device per quarter (or more frequently if you’re able). NetSPI recommends that you look at your firewalls as often as you can, within reason. 
• Firewall checklist (long) – same as above, but this includes some long form descriptions about why this is on the list, as well as example values. The example can be neutral, positive, or negative. 

So how do I use these documents, you ask? Print out one of the checklists above. The first couple times it may help to use the long form with the explanations so you know what I’m asking and why. Once you’re comfortable, you can start using the short form. Every quarter, or whenever your firewall configuration cycle rolls around, print out a form for each of your firewall and access control devices. Go through the device configuration and fill out the form to the best of your ability. If you get stuck, reach out to any internal network and firewall administrators to help you understand what to write down. When you find an item that needs attention, create an internal project or ticket to correct that configuration or deployment problem. File the form away in a safe place. That’s it!

Over time, you should see the overall configuration of the firewalls improve, and you have a review trail that you can give your auditor if they ask about a firewall review requirement. When the business considers buying new firewalls or access control devices, pull out a form and run through it for each proof of concept deployment in your demo environment. If you buy a product and deploy it in demo, run through the checklist before you sign off on the deployment to your production environment.

This is version 1 of the document. If you have any feedback, or you know of other useful firewall checklists, please let me know.

The post Firewall Configuration Review appeared first on NetSPI.

Vendors

The first place to look for security guidance is always the vendors:

Microsoft Hyper-V

Microsoft released Hyper-V as a free hypervisor that runs on top of windows with Windows Server 2008. Here are a couple resources you can use: https://technet.microsoft.com/en-us/library/dd569113.aspx – Hyper-V Security Guide https://www.microsoft.com/en-us/download/details.aspx?id=16650 – Hyper-V Security Guide download

VMware

VMware is the best known, longest running hypervisor out there. Their products have gone through a lot of changes over the years, so it’s pretty important to track the version of VMware/vSphere you’re using closely. Listed below are the hardening guides for each version:

VMware 3 (Seriously? You should update!):

https://www.vmware.com/pdf/vi3_security_hardening_wp.pdf

vSphere 4.0:

https://www.vmware.com/files/pdf/techpaper/VMware_vSphere_HardeningGuide_May10_EN.pdf

vSphere 4.1:

https://www.vmware.com/files/pdf/techpaper/VMW-TWP-vSPHR-SECRTY-HRDNG-USLET-101-WEB-1.pdf

vSphere 5 (brand new):

https://communities.vmware.com/servlet/JiveServlet/downloadBody/19605-102-1-26036/HardeningGuide-vSphere50-v1.0.xlsx

Xen

Xen is a very popular open source hypervisor. I couldn’t find any specific hardening documents for Xen, but I believe the standard Linux hardening guides will go a long way. Here is a portal for their documentation: https://xen.org/support/documentation.html

Third Parties

Vendors are great and all, but I think objective third parties provide the most insight into the problem, as they’re not trying to sell you on how great their software is or ram virtual security appliances down your throat.

Defense Information Systems Agency (DISA) STIG:

https://communities.vmware.com/servlet/JiveServlet/downloadBody/9482-102-1-6731/esx_server_stig_v1r1_final.pdf

Cloud Security Alliance:

https://cloudsecurityalliance.org/csaguide.pdf

SANS:

https://www.sans.org/reading_room/analysts_program/vmware-guide-may-2010.pdf

CIS Security Benchmarks:

https://benchmarks.cisecurity.org/en-us/?route=downloads.browse.category.benchmarks.servers.virtualization

Regulatory

Aren’t regulations fun? While not exactly a security data point, regulation guidance is useful at times.

PCI Security Standards Council:

https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf

The post Virtualization Security Resources appeared first on NetSPI.