About Brent Huston

I am the CEO of MicroSolved, Inc. and a security evangelist. I have spent the last 20+ years working to make the Internet safer for everyone on a global scale. I believe the Internet has the capability to contribute to the next great leap for mankind, and I want to help make that happen!

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!

Touchdown Task for November- Network Segmentation Review

Whether it is budget preparation or annual project planning, the end of the year always leads us to think of the “big picture”. The touchdown task for this month is to review your network architecture maps and diagrams. First of all, make sure they are up-to-date. But secondly, look for indications that your network might be too flat. That is, do you have proper network segmentation between all of your information resources? Are your firewalls placed properly throughout your environment? 

 

A “flat” network architecture allows attackers who have gained a foothold on the internal (and sometimes even the external — you do have a layered DMZ, right?) network full visibility to internal systems and to move freely through workstation and server space. 

 

If you see some re-architecting that should be done, make note of it now. Depending on the complexity of the work, either schedule the re-architecture for a slow period at the end of this year or create a work plan for 2014. 


As always, thanks for reading and keep your eyes on the goal!

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. 🙂

Brent Huston to Lead ICS/SCADA Honeypot Webinar with SANS

Our Founder and CEO, Brent Huston (@lbhuston) will be leading a SANS webinar on ICS/SCADA honeypots. The webinar is scheduled for November, 25th, 2013 and you can find more information and register by visiting this page.

The webinar will cover when honeypots are and are not useful, basic deployment strategies and insights into using them for detection in field deployments and control environments. 

Check it out, tune in and give Brent a shout out on Twitter. Thanks for reading and we hope you enjoy the webinar.

Thanks for Making the 3rd Mid-West ICS/SCADA Security Symposium a Success

Thanks to the attendees and speakers who participated yesterday in the 3rd Annual ICS/SCADA Security Symposium. It was another great event and once again, the center of the value was in the interactions of the audience with the speakers and each other. It’s great to hear asset owners discuss what is working, what is challenging and what is critical in their minds.

Thanks again to those who attended and contributed to making this event such a wonderful thing again this year. We appreciate it and we can’t wait until next year to do it all again.

Thank YOU!

Three Ways to Help Your Security Team Succeed

Over the years, I have watched several infosec teams grow from inception to maturity. I have worked with managers, board members and the front line first responders to help them succeed. During that time I have keyed in on three key items that really mean the difference between success and failure when it comes to growing a teams’ capability, maturity and effectiveness. Those three items are:

  • Cooperative relationships with business units – groups that succeed form cooperative, consultative relationships with the lines of business, other groups of stakeholders and the management team. Failing teams create political infighting, rivalry and back stabbing. The other stakeholders have to be able to trust and communicate with the infosec team in order for the security team to gain wisdom, leverage and effective pro-active traction to reform security postures. If the other teams can’t trust the security folks, then they won’t include them in planning, enforce anything beyond the absolute minimum requirements and/or offer them a seat at their table when it comes time to plan and execute new endeavors. Successful teams operate as brethren of the entire business, while failing teams either play the role of the “net cop” or the heavy handed bad guy — helping neither themselves, their users or the business at large.
  • Embracing security automation and simplification – groups that succeed automate as much of the heavy lifting as possible. They continually optimize processes and reduce complex tasks to simplified ones with methodologies, written checklists or other forms of easy to use quality management techniques. Where they can, they replace human tasks with scripting, code, systems or shared responsibility. Failing teams burn out the team members. They engage in sloppy processes, tedious workflows, use the term “we’ve always done it this way” quite a bit and throw human talent and attention at problems that simple hardware and software investments could eliminate or simplify. If you have someone “reading the logs”, for example, after a few days, they are likely getting less and less effective by the moment. Automate the heavy lifting and let your team members work on the output, hunt for the bad guys or do the more fun stuff of information security. Fail to do this and your team will perish under turnover, malaise and a lack of effectiveness. Failing teams find themselves on the chopping block when the business bottom line calls for reform.
  • Mentoring and peer to peer rotation – groups that succeed pay deep attention to skills development and work hard to avoid burn out. They have team members engage in mentoring, not just with other security team members, but with other lines of business, stakeholder groups and management. They act as both mentors and mentees. They also rotate highly complex or tedious tasks among the team members and promote cross training and group problem solving over time. This allows for continuous knowledge transfer, fresh eyes on the problems and ongoing organic problem reduction. When innovation and mentoring are rewarded, people rise to the occasion. Failing groups don’t do any of this. Instead, they tend to lock people to tasks, especially pushing the unsexy tasks to the low person on the totem pole. This causes animosity, a general loss of knowledge transfer and a seriously bad working environment. Failing teams look like security silos with little cross training or co-operative initiatives. This creates a difficult situation for the entire team and reduces the overall effectiveness for the organization at large.

Where does your team fit into the picture? Are you working hard on the three key items or have they ever been addressed? How might you bring these three key items into play in your security team? Give us a shout on Twitter (@microsolved or @lbhuston) and let us know about your successes or failures. 

Thanks for reading, and until next time, stay safe out there!