What Do You Want from InfoSec Next Year?

Given that so many firms will spend the end of the year issuing their opinions and predictions for next year, we thought we’d go against the grain, so to speak, and instead ASK YOU what you want the next year to bring?

What do you hope the information security community accomplishes or changes in a major way next year?

What new services or changes to service offerings would you most like to see?

If you could wake up on the first morning of the new year and have a brand new security product on your door step, what would it do for you? How would you like it to operate? What do you most fantasize about accomplishing?

What projects would you like to see grow in 2014? What terms, techniques or technologies would you like to see left behind in 2013?

Drop us a line via Twitter (@microsolved or @lbhuston) or via our Facebook page (http://facebook.com/microsolved) and let us know what you dream about. We’ll work hard to see if we can make your holiday season wishes come true! 

CMHSecLunch is Monday & a Quick Question

Just a reminder that CMHSecLunch is Monday, December 9th at North Market. The party starts at 11:30am Eastern and will run through about 1pm Eastern. Come on out and hang with us! 

We usually eat upstairs on the side nearest High Street and the end near the elevator. Look for a group of security geeks hanging out in that area and sit down for a snack and a chat.

Hope to see you then!

And now for the quick question. What would you think of also having a webex during the same period of time for those who are unable to attend physically or who are friends who have moved away? If that would interest you and you might enjoy it, drop me a line on Twitter and let me know (@lbhuston). I am considering this, but I won’t pouch forward unless at least 10 people ping me on Twitter or some other way. 

Thanks for reading and I hope to see you on the 9th!

** You can find out more about the event or RSVP by visiting our eventbrite site here

Using HoneyPoint to Inventory Windows Boxes on a Segment

For quite some time now, we have been using HoneyPoint Agent and Console to do some passive inventory and mapping exercises for clients, particularly those involved in ICS and SCADA deployments where active scanning to get inventories is often strongly discouraged. We had particular success with a specific client in this space a couple of weeks ago, and I wanted to discuss it here, since it has proven itself to be a useful tool and is on the top of my mind at the moment.

To get an inventory of the Windows systems on a collision domain, you simply install the Agent on a Linux box (or I suggest using the virtual appliance we already have built for your ease) and implement it and the Console. Once HoneyPoint is operational, you configure a UDP listener on port 138. From there, all of the NETBios speaking Windows systems will begin to send traffic to the host, as per the usual behavior of those systems. In this case, however, HoneyPoint will capture each source IP and log it to the Console. It will also capture the UDP datagrams from that conversation and place them as event data in the logs. By reviewing the source IPs, you can quickly and easily take stock of the Windows systems on the collision domain without sending any traffic at all to the systems. As a bonus, if you dig into the datagram data, you will also see the names of the hosts and other information.

Most of the time, this technique captures only Windows boxes, but if you have other devices out there running NETBios, they will likely get detected as well. This can include embedded systems, Unix systems running SAMBA, printers and copiers, Windows CE systems (often seen in many field equipment deployments), etc. You might be surprised what you can find.

Try this with a laptop, and move the laptop around your environment. You can pretty quickly and easily get an inventory by collision domain. You can also try dialing other NETBios ports and see if you get traffic that is routed across your switching fabric. Depending on your configuration, you might be able to gather a great deal of inventory data from a single location (especially if your network is flat and switches are poorly configured).

Give this a shot or get in touch if you would like us to come onsite and perform the inventory for you. We think it is a pretty useful technique and one that many folks are enjoying the benefits of. Let us know what you think when you give it a run in your network!

As always, thanks for reading, and until next time, stay safe out there!

PS – You can also do this with HoneyPoint Personal Edition on a Linux system, which makes it very easy and cheap to do if you don’t want to invest in a full blown HoneyPoint Security Server implementation. (You should invest though, it is a FANTASTIC detection tool!)

**(The link above is for HPPE on Windows, but if you purchase a license and contact us, we will send you the Linux build right away. You can’t easily capture port 138/UDP traffic in Windows HPPE because Windows has those ports in use…)

CMHSecLunch for December is the 9th

Just a reminder that the CMHSecLunch for December will be on the 9th at North Market. As always, admission is free and everyone is welcome. Come on out and see your friends.

As usual, to RSVP and let others know you are attending, or to view more information about the event, you can visit the eventbrite site here.

See you there! Or, on Twitter with the hashtag #CMHSecLunch if you can’t make it or are out of the Columbus area. The more the merrier!

Code of Conduct Research

We have begun working on another project around helping organizations better protect their information assets and the reputations of both their employees and their firms at large. As part of that project, we would like to solicit some feedback from the readership of the blog. 

Does your organization have a code of conduct for employees? Does is have a written code of conduct for management, board members and/or public relations campaigns? 

Is it a living code of conduct or is it a stagnant piece of policy? How often is it updated? Does it cover social media presence, community engagement and/or public perception of the firm or individual?

Who audits the code of conduct and how is it monitored for violations? 

Please feel free to give us your thoughts on the code of conduct and which industry you are in. We are taking responses via email (info <at> microsolved <dot> com) or via Twitter (@lbhuston). 

Thanks for responding. Responses will be entered into a random drawing for a Starbucks gift card, so respond for a chance to win some java goodness. 🙂

October Touchdown Task: Phone System Review

This month’s Touchdown Task is to take an hour and give your phone system security a quick review. PBX hacking, toll fraud and VoIP attacks remain fairly common and many organizations don’t often visit the security of their phone systems. Thus, a quick review might find some really interesting things and go a long way to avoiding waste, fraud and abuse.

If you have a traditional PBX/analog phone system, here are some ideas for you to check out.

If you have a VoIP-based system, here are some checks to consider. (Note that this is a STIG in a  zip file). 

Generally speaking, you want to check passwords on voice mail boxes, give a look over to make sure that the phone system has some general logging/alerting capability and that it is turned on. Pay attention to out going dialing rules and test a few to make sure arbitrary calls can’t be made remotely. On the personnel side, make sure someone is actively monitoring the phone system, auditing the bill against “normal” and adding/deleting entries in the system properly.

Give the phone system a bit of your time. You never know what you might learn, and you might avoid tens to hundreds of thousands of dollars in fraud and abuse.

Thanks for reading and I hope you are enjoying the season! 

Blast From the Past: D-Link Probes in the HITME

We got a few scans for an old D-Link router vulnerability that dates back to 2009. It’s interesting to me how long scanning signatures live in online malware and scanning tools. This has lived for quite a while. 

Here are the catches from a HoneyPoint Personal Edition I have deployed at home and exposed to the Internet. Mostly, this is just to give folks looking at the scans in their logs an idea of what is going on. (xxx) replaces the IP address… 

2013-10-02 02:46:13 – HoneyPoint received a probe from 71.103.222.99 on port 80 Input: GET /HNAP1/ HTTP/1.1 Host: xxxx User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32) WebWasher 3.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://xxxx/ Authorization: Basic YWRtaW46dWA+NXhZQlU1d2VR Connection: keep-alive

2013-10-02 03:22:13 – HoneyPoint received a probe from 71.224.194.47 on port 80 Input: GET /HNAP1/ HTTP/1.1 Host: xxxx User-Agent: Opera/6.x (Linux 2.4.8-26mdk i686; U) [en] Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://xxxx/ Authorization: Basic YWRtaW46InkwYi4qMF5wL05G Connection: keep-alive

This probe is often associated with vulnerable D-Link routers, usually older ones, those made between 2006 and mid-2010. The original release and proof of concept exploit tool is here. The scan has also been embedded into several scanning tools and a couple of pieces of malware, so it continues to thrive.

Obviously, if you are using these older D-Link routers at home or in a business, make sure they are updated to the latest firmware, and they may still be vulnerable, depending on their age. You should replace older routers with this vulnerability if they can not be upgraded. 

The proof of concept exploit also contains an excellent doc that explains the HNAP protocol in detail. Give it a read. It’s dated, but remains very interesting.

PS – As an aside, I also ran the exploit through VirusTotal to see what kind of detection rate it gets. 0% was the answer, at least for that basic exploit PoC. 

Infosec, The World & YOU Episode 3 is Out!

Our newest episode is out, and this time we are joined by a very special guest, @TSGouge who discuss social engineering for companies and on the nation state scale. Victoria reveals her new plans to take over the world and Brent tries to keep up with these gals, who are straight up geniuses. We also pontificate on Syria and the potential for cyber-fallout from the action going on over there.

Check it out here

Have a global real world/cyber issue you want us to tackle? Observed an odd event that ties to a real world cause in the Internets? Drop us a line ~ we’d love to hear about it or get you on the show! 

You can find Brent on Twitter at @lbhuston and Victoria stars as @gisoboz. Get in touch! 

Ask The Experts: New Device Check Lists

This time around on Ask The Experts, we have a question from a reader and it got some great responses from the team:

 

Q: “I need a quick 10 item or less checklist that I can apply to new devices when my company wants to put them on our network. What kinds of things should I do before they get deployed and are in use around the company?”

 

Bill Hagestad started us off with:

The Top 10 checklist items a CISO/or equivalent authority should effectively manage before installing, configuring and managing new devices on a network includes the following;

 

1)Organize your staff and prepare them for the overall task of documenting and diagramming your network infrastructure – give them your commander’s network management intent;

2)Create a physical and logical network map – encourage feedback from your team regarding placement of new hardware and software;

3)Use industry standards for your network including physical and logical security, take a good look at NIST Special Publication SP 800-XX Series;

4)Make certain that you and your team are aware of the requisite compliance standards for your business and industry, it will help to ensure you are within legal guidelines before installing new devices or perhaps you may discover the hardware or software you are considering isn’t necessary after all;

5)Ensure that after you have created the necessary network maps for your infrastructure in Step 2) above, conduct a through inventory of all infrastructure which is both critical and important to your business, then document this baseline;

6)Create a hardware/software configuration change procedure; or if you already have his inlace, have your team review it for accuracy; make certain everyone on the team knows to document all changes/moves/additions on the network;

7)Focus not only on the correlation of newly implemented devices on the internal networks but also look at the dependencies and effects on external infrastructure such as voice/data networks – nothing worse than making an internal change to your network and having your Internet go down unnecessarily;

8)Ensure that new network devices being considered integrate gracefully into your existing logging and alerting mechanisms; no need to install something new only to have to recreate the proverbial wheel in order to monitor it;

9)Consider the second & third order effects of newly installed devices on the infrastructure and their potential impact on remote workers and mobile devices used on the network;

10)Install HoneyPoint Security Server (HPSS) to agentlessly & seamlessly monitor external and potential internal threats to your newly configured network….

 

Of course a very authoritative guide is published by the national Security Agency called appropriately “Manageable Network Plan” and available for download @:

 

http://www.nsa.gov/ia/_files/vtechrep/ManageableNetworkPlan.pdf


Jim Klun added:

1. Make sure the device is necessary and not just a whim on the part of management.   Explain that each new device increases risk. 

2. If the device’s function can be performed by an existing internal service, use that service instead. 

3. Inventory new devices by name, IP addresses, function and – most importantly – owners.  There should be a device owner and a business owner who can verify continued need for the device.  Email those owners regularly,   querying them about continued need. Make sure that these folks have an acknowledged role to support the application running on the devices and are accountable for its security. 

4. Research the device and the application(s) its support.  Have no black boxes in your datacenter.  Include an abstract of this in the inventory. 

5. Make sure a maintenance program is in place – hold the app and device owner accountable. 

6. Do a security audit of the device wehn fully configured. Hit it with vulnerability scanners and make sure that this happens at least quarterly. 

7. Make sure monitoring is in place and make very sure all support staff are aware of the device and any alerts it may generate. Do not blind-side the operations staff. 

8. If the device can log its activities ( system and application ) to a central log repository, ensure that happens as part of deployment. 

9. Make sure the device is properly placed in your network architecture. Internet-exposed systems should be isolated in an Internet DMZ.  Systems holding sensitive data should similarly be isolated. 

10. Restrict access to the device as narrowly as possible. 

 

Finally.. if you can, for every device in your environment, log its network traffic and create a summary of what is “normal” for that device.  

Your first indication of a compromise is often a change in the way a system “talks”. 

 

Adam Hostetler chimed in with: 

Will vary a lot depending on device, but here are some suggestions

 

1. Ensure any default values are changed. Passwords, SNMP strings, wireless settings etc.

2. Disable any unnecessary services

3. Ensure it’s running the latest firmware/OS/software

4. Add the device to your inventory/map, catalog MAC address, owner/admin, etc.

5. Perform a small risk assessment on the device. What kind of risk does it introduce to your environment? Is it worth it?

6. Test and update the device in a separate dev segment, if you have one.

7. Make sure the device fits in with corporate usage policies

8. Perform a vulnerability assessment against the device. 

9. Search the internet for any known issues, vulnerabilities or exploits that might effect the device.

  1. Configure the device to send logs to your logging server or SEIM, if you have one.

 

And John Davis got the last word by adding: 

From a risk management perspective, the most important thing a CISO needs to ensure is in place before new devices are implemented on the network is a formal, documented Systems Development Life Cycle or Change Management program. Having such a program in place means that all changes to the system are planned and documented, that security requirements and risk have been assessed before devices have purchased and installed, that system configuration and maintenance issues have been addressed, that the new devices are included in business continuity planning, that proper testing of devices (before and after implementation on the network) is undertaken and more. If a good SDLC/Change Management program is not in place, CISOs should ensure that development and implementation of the program is given a high priority among the tasks they wish to accomplish.

 

Whew, that was a great question and there is some amazing advice here from the experts! Thanks for reading, and until next time, stay safe out there! 

 

Got a question for the experts? Give us a shout on Twitter (@microsolved or @lbhuston) and we’ll base a column on your questions!

Yo, MSI Raps Podcast Episode 1

This is the latest version of Yo, MSI Raps. We have decided to make these episodes open to public finally, so we will start with this one.

This is an open round table discussion between members of the MSI Technical Team. It is candid, friendly and, we hope, interesting. 🙂

This time around, the team talks about privacy, the news around the NSA collection of data and impacts of surveillance on liberty. 

You can check out the podcast here!

Look for these sessions to be released more frequently and on topics that are in the news. We hope you enjoy them, and feel free to give us feedback via Twitter (@lbhuston or @microsolved) and/or via the comments section.

Thanks for listening!