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!

Introducing ClawBack :: Data Leak Detection Powered By MicroSolved

Cb 10We’ve worked with our clients and partners to put together a world-class data leak detection platform that is so easy to use that most security teams have it up and running in less than five minutes. No hardware appliance or software agent to deploy, no console to manage and, best of all, affordable for organizations of any size.

In short, ClawBack is data leak detection done right.

There’s a lot more to the story, and that’s why we put together this short (3 minute) video to describe ClawBack, its capabilities and why we created it. Once you check it out, we think you’ll see just how ClawBack fits the mission of MSI to make the online world safer for all of us.

View the video here.

You can also learn a lot more about ClawBack, its use cases and some of the ways we hope it can help you here. On that page, you can also find pricing for three different levels of service, more videos walking you through how to sign up and a video demo of the platform.

Lastly, if you’d like to just get started, you can visit the ClawBack Portal, and select Register to sign up and put ClawBack to work immediately on providing detection for your leaked data.

In the coming weeks, we’ll be talking more about what drove us to develop ClawBack, the success stories we’ve had just while building and testing the platform, and provide some more specifics about how to make the most of ClawBack’s capabilities. In the meantime, thanks for reading, check it out and if you have any questions, drop us a line.

State of Security Podcast Episode 17 is Out!

In this episode (~45 minutes), I answer questions from the audience around blockchain and smart contract security considerations. I cover some of the reasons why I think these technologies are important, what their potential impacts are likely to be and how information security teams should prepare. Some of the questions drift into changes around store of value, investment insights and other closely related topics.

This episode is sponsored by MachineTruth™ – a new passive, analytics-based solution for network inventory, traffic analysis and security baselining. Learn more at  http://www.machinetruth.net.

 

State of Security Podcast Episode 16 is Out!

This episode is a tidbit episode, weighing in just under 20 minutes. I sat down last week with Megan Mayer (@Megan__Bytes) in the lobby bar of the Hyatt during the Central Ohio Security Summit. Pardon the background noise, but we riffed on what Megan believes are the top 3 things that every security manager or infosec team should do this week. She had some great insights and I think her points are fantastic.

Give it a listen, and as always, if you have feedback or have someone in mind that you’d like to have interviewed on the podcast or a topic that you’d like to see covered, drop me a line (@lbhuston). 

As always, thanks for listening and stay safe out there!

 

Network Segmentation with MachineTruth

network segmentation with MachineTruth

About MachineTruthTM

We’ve just released a white paper on the topic of leveraging MachineTruth™, our proprietary network and device analytics platform, to segment or separate network environments.

Why Network Segmentation?

The paper covers the reasons to consider network segmentation, including the various drivers across clients and industries that we’ve worked with to date. It also includes a sample work flow to guide you through the process of performing segmentation with an analytics and modeling-focused solution, as opposed to the traditional plug and pray method, many organizations are using today.

Lastly, the paper covers how MachineTruthTM is different than traditional approaches and what you can expect from such a work plan.

To find out more:

If you’re considering network segmentation, analysis, inventory or mapping, then MachineTruthTM is likely a good fit for your organization. Download the white paper today and learn more about how to make segmentation easier, safer, faster and more affordable than ever before!

Interested? Download the paper here:

https://signup.microsolved.com/machinetruth-segmentation-wp/

As always, thanks for reading and we look forward to working with you. If you have any questions, please drop us a line (info@microsolved.com) or give us a call (614-351-1237) to learn more.

State Of Security Podcast Episode 15 is out!

In this episode, the tables get turned on me and I become the one being interviewed. The focus is on honeypots, intrusion deception and bounces from technology to industry and to overall trends.

This is a great conversation with an amazing young man, Vale Tolpegin, a student from Georgia Tech with an amazing style and a fantastic set of insights. He really asks some great questions and clarifying follow ups. This young man has a bright future ahead!

Tune in and check it out! Let me know on Twitter (@lbhuston) what you liked, hated or what stuck with you.

Why Our Firm Loves The Columbus Cyber Security Community

Yesterday, I was doing an interview with one of my mentees. The questions she asked brought up some interesting points about MSI, our history and Columbus. I thought I would share 3 of the questions with the SoS readers:

How Did The Firm End Up In The Columbus Cyber Security Community?

Brent Huston:

“You have to remember that when I founded MicroSolved, back in 1992, there wasn’t a strong commercial Internet yet. Most of the electronic commerce efforts and digital business was done via dial-up or dedicated networks. I came to Columbus in 1988 to go to school and eventually ended up at DeVry. I was working at Sterling Software and doing a lot of experimentation with technology. Somehow, I got completely interested in security, hacking, phreaking and online crime. I took that passion and began to explore building it into a business. There were a few of us starting consulting companies back then, and Columbus was certainly an interesting place to be in the early 90s. Eventually, Steve Romig, from The Ohio State University started putting groups together – meeting at different parks and restaurants. That was the first place I really identified as the beginning of a security community in the city.”

Continue reading

What to Do When You Gotta Have FTP

FTP has been around for a long time. While it has grown long in the tooth, it continues to be an essential protocol for many business processes – especially in the financial industry. Clearly, it is a functional and useful tool, but it certainly also comes with significant security risk.

First of all, in its bare form, it is a plain-text protocol and open to capture and observation by anyone in the communications path. Firewall rules pertaining to its different modes of operation are also often confusing for novice network techs and admins, sometimes leading to inadvertent security issues in its deployment. Worse yet, it is a commonly scanned, brute forced and exploited attack surface as well.

But, if you are any of the industry firms where FTP is still a mainstay (banking, wealth management, title management, loan processing, imaging, etc.) how can you do your work and still try and keep security as tight as possible?

Let’s start with identification. You need to know if you have FTP exposed to the Internet, partner networks or on any segments where trust is low. For each instance, you need to understand the data that is being moved, the sources and destinations of that data, the authentication mechanism and model in play (you’re using strong passwords and MFA, right?) and you need to carefully consider the trusts that exist within the system and network environment where the server lives.

Then, you can address prevention. Do you have an alternative to replace it with SFTP or another encrypted protocol? Does it have to be exposed to the world, or can you use access controls or restrict the source IPs allowed to connect to it with either host configurations or firewall rules? How is the server component kept updated to ensure that patching is taking place?

Let’s talk detection. Are logs being generated, stored and reviewed? How would you know if a brute force attack had exposed your data or credentials? How would you identify malicious behavior against the FTP service? Many companies we talk to (especially smaller ones), don’t have good plans for monitoring these systems, even though they may be mission critical.

If something bad happened, you should also have a response process in place for managing FTP data. What would you do if the data were compromised? What would you need to do if the FTP server were not available or the network was down for an extended period? Running table top exercises is usually a good way to develop and refine the policies and processes needed around FTP data exchanges.

Lastly, your organization should have a plan for recovering from problems with the FTP server. Is the data backed up within an appropriate window and how would/could that data be restored? What would be the business and financial challenges to recovery? How would you handle notification of partners or customers that were impacted?

These are pretty basic questions for infosec teams, but for many organizations with more ad-hoc IT staff or for smaller organizations with only contractors they can be daunting. 

Hopefully our advice above gets you thinking about FTP. As always, if you have questions or need assistance executing any of the above – MSI is here to help. But, if your team takes this list and executes against it – you should be much better off than before the project began.

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

We’re Growing Again!

From social media:

Got #infosec skills? We’re looking for a new team member to join MicroSolved. Pen-testing, threat intel & innovation are core reqs. Ethics, rapid learning, positivity are must haves. #Columbus preferred. Get in touch!  

Here is a bit more information: 

This engineer will engage with clients to review technical systems/applications, perform vulnerability assessments/pen-testing, application assessments, cyber threat intelligence assessments, network segmentation analysis, validate technical findings and support customers with security issues across the attack event horizon. 

Projects will cover the scope of networks, applications, security devices, servers/systems and likely embedded systems/components. Deep enterprise network knowledge in one or more areas of networking and/or security is a requirement. Familiarity with NIST standards/cyber security frameworks is preferred. 

To apply, send a resume and cover letter to (jobs <at> microsolved <dot> com). Please, no recruiters and no phone calls. If you have questions, please reach out on Twitter to @lbhuston. 

Thanks! 

Are You Seeing This? Join a Threat Sharing Group!

Just a quick note today about threat sharing groups. 

I am talking to more and more companies and organizations that are putting together local, regional or vertical market threat sharing groups. These are often adhoc and usually driven by security practitioners, who are helping each other with cooperative defenses and sharing of new tactics and threat patterns (think TTPs (tactics, techniques & procedures)) or indicators of compromise (IOCs). Many times, these are informal email lists or RSS feeds that the technicians subscribe to and share what they are seeing in the trenches. 

A few folks have tried to commercialize them, but in most cases, these days, the sharing is simply free and open. 

If you get a chance to participate in one or more of these open source networks, you might want to check it out. Many of our clients are saying great things about the data they get via the networks and often they have helped contain incidents and breaches in a rapid fashion.

If you want to discuss your network, or if you have one that you’d like me to help promote, hit me up on Twitter (@lbhuston). If you are looking for one to join, check Twitter and I’ll share as folks allow, or I’ll make private connections as possible. 

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

Where Does Trouble Come From?

One of the most common questions I get is, “Where does attack traffic come from?”. I want to present a quick and dirty answer, just to show you how diverse illicit traffic sources are. 

To give you a glimpse into that, here is a list of the top 20 ISPs, based on the number of unique malicious source IP addresses who touched one of my HoneyPoint deployments in a single 24 hour period.

The list:

9 korea telecom
7 hinet
6 dynamic distribution ip’s for broadband services ojsc rosteleom, regional branch “urals”
5 sl-reverse
5 sfr
5 rr
5 chinanet jiangsu province network china telecom no.31,jingrong street beijing 100032
5 china mobile communications corporation mobile communications network operator in china internet service provider in china
4 turknet-dsl
4 superonline
4 sbcglobal
4 chinanet jiangsu province network china telecom 260 zhongyang road,nanjing 210037
3 zenlayer inc
3 virginm
3 verizon
3 totbb
3 jsc rostelecom regional branch “siberia”
3 intercable
3 comcastbusiness
3 comcast
3 charter
3 broadband multiplay project, o/o dgm bb, noc bsnl bangalore
3 as13285

As you can see by the above, the list is pretty diverse. It covers sources in many countries and across both domestic and foreign ISPs. In my experience, the list is also pretty dynamic, at least in terms of the top 10-20 ISPs. They tend to spike and fall like waves throughout different time periods. One of these days, maybe I will get around to visualizing some of that data to get a better view of the entropy around it. But, for now, I hope this gives you an idea of the diversity in sources of attacks.

The diversity also makes it very difficult to baseline log activity and such. As such, there may be some effective risk reduction in blocking ISPs by netblock, if your organization can tolerate the risk associated with doing so. But, more on that in another post. Hit me up on Twitter (@lbhuston) and let me know what your firm’s experience with that type blocking has been; if you’ve tried it or are doing it today. I’d love to hear if it reduced log noise, made traffic modeling easier or led to any specific risk reductions.

Thanks for reading!