Category Archives: How To

Monitoring: an Absolute Necessity (but a Dirty Word Nonetheless)

Posted on by
3

There is no easier way to shut down the interest of a network security or IT administrator than to say the word “monitoring”. You can just mention the word and their faces fall as if a rancid odor had suddenly entered the room! And I can’t say that I blame them. Most organizations do not recognize the true necessity of monitoring, and so do not provide proper budgeting and staffing for the function. As a result, already fully tasked (and often times inadequately prepared) IT or security personnel are tasked with the job. This not only leads to resentment, but also virtually guarantees that the job is will not be performed effectively.

And when I say human monitoring is necessary if you want to achieve any type of real information security, I mean it is NECESSARY! You can have network security appliances, third party firewall monitoring, anti-virus packages, email security software, and a host of other network security mechanisms in place and it will all be for naught if real (and properly trained) human beings are not monitoring the output. Why waste all the time, money and effort you have put into your information security program by not going that last step? It’s like building a high and impenetrable wall around a fortress but leaving the last ten percent of it unbuilt because it was just too much trouble! Here are a few tips for effective security monitoring:

  • Properly illustrate the necessity for human monitoring to management, business and IT personnel; make them understand the urgency of the need. Make a logical case for the function. Tell them real-world stories about other organizations that have failed to monitor and the consequences that they suffered as a result. If you can’t accomplish this step, the rest will never fall in line.
  • Ensure that personnel assigned to monitoring tasks of all kinds are properly trained in the function; make sure they know what to look for and how to deal with what they find.
  • Automate the logging and monitoring function as much as possible. The process is difficult enough without having to perform tedious tasks that a machine or application can easily do.
  • Ensure that you have log aggregation in place, and also ensure that other network security tool output is centralized and combined with logging data. Real world cyber-attacks are often very hard to spot. Correlating events from different tools and processes can make these attacks much more apparent. 
  • Ensure that all personnel associated with information security communicate with each other. It’s difficult to effectively detect and stop attacks if the right hand doesn’t know what the left hand is doing.
  • Ensure that logging is turned on for everything on the network that is capable of it. Attacks often start on client side machines.
  • Don’t just monitor technical outputs from machines and programs, monitor access rights and the overall security program as well:
  • Monitor access accounts of all kinds on a regular basis (at least every 90 days is recommended). Ensure that user accounts are current and that users are only allocated access rights on the system that they need to perform their jobs. Ensure that you monitor third party access to the system to this same level.
  • Pay special attention to administrative level accounts. Restrict administrative access to as few personnel as possible. Configure the system to notify proper security and IT personnel when a new administrative account is added to the network. This could be a sign that a hack is in progress.
  • Regularly monitor policies and procedures to ensure that they are effective and meet the security goals of the organization. This should be a regular part of business continuity testing and review.
Thanks to John Davis for writing this post.

HoneyPoint IP Protection Methodology

Posted on by
5

Here’s another use case scenario for HoneyPoint Security Server. This time, we show the methodology we use to scope a HoneyPoint implementation around protecting a specific set of Intellectual Property (IP). 

If you would like an in-depth discussion of our process or our capability, please feel free to reach out to us and schedule a call with our team. No commitment and no hard sale, guaranteed.

If the graphic below is blurry on your device, you can download a PDF version here.

HP_IPProtection

HoneyPoint Trojans Overview

Posted on by
4

Here’s another quick overview graphic of how HoneyPoint Trojans work. We have been using these techniques since around 2008 and they are very powerful. 

We have incorporated them into phishing exercises, piracy studies, incident response, intrusion detection, intelligence gathering, marketing analysis and even privacy research. To hear more about HoneyPoint Trojans, give us a call.

If the graphic below is blurry on your device, you can download a PDF version here.

HPTrojanOverview

HoneyPoint in a Point of Sale Network

Posted on by
7

We have been getting a LOT of questions lately about how HoneyPoint Security Server (HPSS) fits into a Point of Sale (POS) network.

To make it pretty easy and as a high level overview, below is a use case diagram we use to discuss the solution. If you would like a walkthrough of our technology, or to discuss how it might fit into your specific use cases, please let us know.

As always, thanks for reading and for partnering with MicroSolved, Inc.

PS – If the graphic below is difficult to read on your device, you can grab a PDF version here.

HP POSNetworks

Incident Response: Are You Ready?

Posted on by
9

All of us suffer from complacency to one extent or another. We know intellectually that bad things can happen to us, but when days, months and years go by with no serious adverse incidents arising, we tend to lose all visceral fear of harm. We may even become contemptuous of danger and resentful of all the resources and worry we expend in aid of problems that never seem to manifest themselves. But this is a dangerous attitude to fall into. When serious problems strike the complacent and unprepared, the result is inevitably shock followed by panic. And hindsight teaches us that decisions made during such agitated states are almost always the wrong ones. This is true on the institutional level as well.

During my years in the information security industry, I have seen a number of organizations founder when struck by their first serious information security incident. I’ve seen them react slowly, I’ve seen them throw money and resources into the wrong solutions, and I’ve seen them suffer regulatory and legal sanctions that they didn’t have to incur. And after the incident has been resolved, I’ve also seen them all put their incident response programs in order; they never want to have it happen again! So why not take a lesson from the stricken and put your program in order before it happens to your organization too? Preparing your organization for an information security incident isn’t really very taxing. It only takes two things: planning and practice.

When undertaking incident response planning, the first thing to do is to examine the threat picture. Join user groups and consult with other similar organizations to see what kinds of information security incidents they have experienced. Take advantage of free resources such as the Verizon Data Breach Reports and US-CERT. The important thing is to limit your serious preparations to the top several most credible incident types you are likely to encounter. This streamlines the process, lessens the amount of resources you need to put into it and makes it more palatable to the personnel that have to implement it. 

Once you have determined which threats are most likely to affect your organization, the next step is to fully document your incident response plan. Now this appears to be a daunting task, but in reality there are many resources available on the Internet that can help guide you through the process. Example incident response plans, procedures and guidance are available from SANS, FFIEC, NIST and many other reputable organizations free of charge. I have found that the best way to proceed is to read through a number of these resources and to adapt the parts that seem to fit your particular organization the best. Remember, your incident response plan is a living document and needs to reflect the needs of your organization as well as possible. It won’t do to simply adopt the first boiler plate you come across and hope that it will work.

Also, be sure that your plan and procedures contain the proper level of detail. You need to spell out things such as who will be on the incident response team, their individual duties during incidents, where the team will meet and where evidence will be stored, who should be contacted and when, how to properly react to different incidents and many other details. 

The next, and possibly the most important step in effective incident response is to practice the plan. You can have the most elegantly written security incident response plan in the world, and it is still doomed to fail during an actual incident if the plan is not practiced regularly. In all my years of helping organizations conduct their table top incident response practice sessions, I have never failed to see the process reveal holes in the plan and provide valuable lessons for the team members who participate. The important thing here is to pick real-world incident scenarios and to conduct the practice as close to the way it would actually occur as possible. We like to only inform a minimum number of response personnel in advance, and surprise the bulk of responders with the event just as it would happen if it were real. Of course there is much more to proper incident response planning and practice than I have included here. But this should start your organization along the right path. For more complete information and help with the process, don’t hesitate to contact your MSI representative. 

Thanks to John Davis for writing this post.

Business Impact Analysis: A Good Way to Jumpstart an Information Security Program

Posted on by
13

Is your organization’s information security program stuck in the era of perimeter firewalls and anti-virus software? Are you a Chief Information Security Officer or IT Manager stuck with the unenviable task of bringing your information security program into the 21st Century? Why not start the ball rolling with a business impact analysis (BIA)? It will provide you with a wealth of useful information, and it takes some of the weight from your shoulders by involving every business department in the organization.

BIA is traditionally seen as part of the business continuity process. It helps organizations recognize and prioritize which information, hardware and personnel assets are crucial to the business so that proper planning for contingency situations can be undertaken. This is very useful in and of itself, and is indeed crucial for proper business continuity and disaster recovery planning. But what other information security tasks can it help you with?

When MSI does a BIA, the first thing we do in issue a questionnaire to every business department and management function in the organization. These questionnaires are completed by the “power users” of the organization who are typically the most experienced and knowledgeable personnel in the business. This means that not only do you get the most reliable information possible, but that one person or one small group is not burdened with doing all of the information gathering. Typical responses include (but are not limited to):

  • A list of every business function each department undertakes
  • All of the hardware assets needed to perform each business function
  • All of the software assets needed to perform each business function
  • Inputs needed to perform each business function and where they come from
  • Outputs of each business function and where they are sent
  • Personnel needed to perform each business function
  • Knowledge and skills needed to perform each business function

So how does this knowledge help jumpstart your information security program as a whole? First, in order to properly protect information assets, you must know what you have and how it moves. In the Top 20 Critical Controls for Effective Cyber Defense, the first control is an inventory of devices and the second control is an inventory of software. The BIA lists all of the hardware and software assets needed to perform each business function. So in effect you have your starting inventories. This not only tells you what you need, but is useful in exposing assets wasting time and effort on your network that are not necessary; if it’s not on the critical lists, you probably don’t need it. 

In MSI’s own 80/20 Rule of Information Security, the first requirement is not only producing inventories of software and hardware assets, but mapping of data flows and trust relationships. The inputs and outputs listed by each business department include these data flows and trust relationships. All you have to do is compile them and put them into a graphical map. And I can tell you from experience; this is a great savings in time and effort. If you have ever tried to map data flows and trust relationships as a stand-alone task, you know what I mean!

Another security control a BIA can help you implement is network segmentation and enclaving. The MSI 80/20 Rule has network enclaving as their #6 control and the Top 20 controls include secure network engineering as their #19 control. The information from a good BIA makes it easy to see how assets are naturally grouped, and therefore the best places to segment the network.

How about egress filtering? Egress filtering is widely recognized as one of the most effect security controls in preventing large scale data loss, and the most effective type of egress filtering employs white listing. White listing is typically much harder to tune and implement than black listing, but is very much more effective. With the information a BIA provides you, it is much easier to construct a useful white list; you have what each department needs to perform each business function at your fingertips.

Then there is skill and security training. The BIA tells you what information users need to know to perform their jobs, so that helps you make sure that personnel are trained correctly and in enough depth to deal with contingency situations. Also, knowing where all your critical assets lie and how they move helps you make sure you provide the right people with the right kind of security training.

And there are other crucial information security mechanisms that a BIA can help you with. What about access control? Wouldn’t knowing the relative importance of assets and their nexus points help you structure AD more effectively? And there is physical security. Knowing where the most crucial information lies and what departments process it would help you set up internal secure areas, wouldn’t it? What other information useful to setting up an effective information security program can you think of that is included in a proper BIA?

Thanks to John Davis for writing this post.

The First Five Quick Wins

Posted on by
10

The Top 20 Critical Controls for Effective Cyber Defense have been around for half a decade now, and are constantly gaining more praise and acceptance among information security groups and government organizations across the globe. One of the main reasons for this is that all of these controls have been shown to stop or mitigate known, real-world attacks. Another reason for their success is that they are constantly being updated and adjusted to fit the changing threat picture as it emerges. 

One of these recent updates is the delineation of the “First Five” from the other “Quick Wins” category of sub-controls included in the guidance (Quick Wins security controls are those that provide solid risk reduction without major procedural, architectural or technical changes to an environment, or that provide substantial and immediate risk reduction against very common attacks – in other words, these are the controls that give you the most bang for the buck). The First Five Quick Wins controls are those that have been shown to be the most effective means yet to stop the targeted intrusions that are doing the greatest damage to many organizations. They include:

  1. Application white listing: Application white listing technology only allows systems to run software applications that are included in the white list. This control prevents both external and internal attackers from implementing malicious and unwanted applications on the system. One caveat that should be kept in mind is that the organization must strictly control access to and modifications of the white list itself. New software applications should be approved by a change control committee and access/changes to the white list should be strictly monitored.
  2. Secure standard images: Organizations should employ secure standard images for configuring their systems. These standard images should utilize hardened versions of underlying operating systems and applications. It is important to keep in mind that these standard images need to be updated and validated on a regular basis in order to meet the changing threat picture.
  3. Automated patching tools and processes: Automated patching tools, along with appropriate policies and procedures, allow organizations to close vulnerabilities in their systems in a timely manner. The standard for this control is patching of both application and operating system software within 48 hours of release.
  4. Removal or replacement of outdated software applications: Many computer networks we test have outdated or legacy software applications present on the system. Dated software applications may have both known and previously undiscovered vulnerabilities associated with them, and are consequently very useful to cyber attackers. Organizations should have mechanisms in place to identify then remove or replace such vulnerable applications in a timely manner just as is done with the patching process above.
  5. Control of administrative privileges and accounts: One of the most useful mechanisms employed by cyber attackers is elevation of privileges. Attackers can turn simple compromise of one client machine to full domain compromise by this means, simply because administrative access is not well controlled. To thwart this, administrative access should be given to as few users as possible, and administrative privileged functions should be monitored for anomalous behavior. MSI also recommends that administrators use separate credentials for simple network access and administrative access to the system. In addition, multi-part authentication for administrative access should be considered. Attackers can’t do that much damage if they are limited to isolated client machines!

Certainly, the controls detailed above are not the only security controls that organizations should implement to protect their information assets. However, these are the controls that are currently being implemented first by the most security-aware and skilled organizations out there. Perhaps your organization can also benefit from the lessons they have learned.

Thanks to John Davis for writing this post.

Touchdown Task for January: Audit Your News Feeds

Posted on by
Reply

This month, our suggested Touchdown Task is for the security team to do an “audit” of their news/RSS feeds and the other mechanisms by which you get advisories, patch and upgrade alerts, breakout information and details about emerging threats.

Since RSS feeds and account names and such can change, it’s a good idea to review these sources occasionally. Are the feeds you depend on timely and accurate? Have you added new technology to your organization since you last reviewed your advisory feeds? Maybe you might need to add a vendor or regulator feed.

Have a discussion with all of your team members and understand who monitors what. Make sure you have good cross communication, but aren’t struggling with a lot of duplicated efforts.

Once you get your news and threat feeds in order, trace how the information is shared and make sure it is getting to the system and network admins who might need it. Do you have the right people getting the right information? If not, adjust. 

Most teams can do this review in less than an hour. So focus, communicate and create a robust way to handle the flow of information.

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

Using HoneyPoint to Inventory Windows Boxes on a Segment

Posted on by
7

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…)

Brent Huston to Lead ICS/SCADA Honeypot Webinar with SANS

Posted on by
5

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.