Security, et al

This is a PowerShell script I developed to use in my own IT audits of Active Directory and for a webinar: 10 Steps to Cleaning Up Active Directory User Accounts and Keeping Them that Way.

It outputs a comma-delimited list of user accounts and their most important properties for IT audit and account management analysis.

Check it out here.

I recently completed a whitepaper for HP ArcSight that details the available logs in Microsoft Exchange and how you can connect those to HP ArcSight.

Even if you are not an ArcSight user you will still want to read this to see which logs are available for auditing in Exchange since our LOGbinder EX application (www.logbinder.com) will be able to get these logs in to any SIEM; not just ArcSight.

Click here to read the whitepaper.

I recently wrote a whitepaper on protecting the unstructured data in your environment.  Unstructured data is a critical security risk and compliance concern for organizations. Your company's emails, documents and spreadsheets contain readily digestible, business-critical information, and your organizatioon is generating more - much more- of those documents every day. How are you protecting that data?

My whitepaper explains what you can do and how to do it.  You can read it here: Randy's White Paper

This code signing hack at Adobe and the available information still leave a lot of unanswered questions.  No one I’ve talked to has been able to get to the bottom of it.  Here’s what have put together.

One of their code-signing servers got hacked and was used to sign some malicious software.  We know of 3 files and their hashes which are listed at http://www.adobe.com/support/security/advisories/apsa12-01.html. 

Were other files signed?  We do not know.

How can I protect against the 3 files we know were signed?  Create Software Restrictions in Group Policy based on the file hashes.

How can I protect against any other files that were signed? Intelligent whitelisting – join me for my webinar tomorrow to learn more.

Can you add the relevant Adobe certificate to your Untrusted Certificates store?  Adobe says doing that won’t stop the malware signed with the certificate but will create a “negative impact on the user experience and execution of valid Adobe software signed with the impacted certificate. Adobe does not recommend using the Untrusted Certificate Store in this situation.” http://forums.adobe.com/message/4741942#4741942. 

What exactly is the “negative impact”?  I assume legit Adobe apps won’t run…

What do I need to do?  Adobe says we need to install updated versions of about 30 applications.  http://helpx.adobe.com/x-productkb/global/certificate-updates.html#main-pars_header_8

What will happen if I don’t update those applications?  What is the risk of not updating? I can find no explanation at all on this.  The FAQ specifically asks this question but I don’t get much from the answer: Adobe is issuing updates for all impacted products to provide customers with software code signed using a new digital certificate. To determine whether an update signed using a new digital certificate is available for your Adobe software installation, please refer to Security certificate updates.

I’m going to cover all the issues in more depth in tomorrow’s webinar and provide short term tactical suggestions and long term strategic recommendations for this new kind of threat that leverages compromised software vendor update infrastructures to deliver and/or trick your computers into running malicious code.

Lumension has agreed to sponsor this webinar and their software update and application whitelisting experts will be joining me.

Please don’t miss this timely real training for free (TM) session.

Folks, here’s a podcast version of a fascinating webinar I just did with Richard Wang who runs SophosLabs. Richard and his team are on the front line of today’s war against malware. One of the most interesting infosec conversations I’ve had in a long time. I hope you enjoy it as much as I did.

Click here:  http://ow.ly/e0YzL

You just can’t cut corners today. In fact you need to be very careful about even “optimizing” your security efforts because it’s so easy misjudge what needs to be secured and what doesn’t; what deserves your attention and what doesn’t.  In fact in a recent discussion with a colleague we concluded that basically, “Today, you have to do everything right”.  I’ll use Flame to demonstrate what I mean. 

Every computer matters

These are wide generalizations but basically in the 90’s we focused on external facing systems: firewalls, web servers, vpn servers, email servers and gateways.  Then, we started the last decade by moving deeper in to the network with more attention on internal servers.  But a widely held mindset persisted that end-user PCs weren’t that important.  You wouldn’t believe how many times I had IT auditors and security folks says they basically don’t worry about endpoints because of a policy that all critical applications and databases are hosted on servers.  Some even relied on a policy forbidding storing confidential information locally on PCs.  (Yes, I know, ludicrous.)  Anyway, today most folks “get it” that endpoints are just as important as servers.  But there’re so many of them and there are so many more threat vectors on endpoints than on servers.

Anyway, even with the recognition of the importance of endpoint security, I hear some folks talking about “endpoints of high-value employees” deserving more attention than the run of them mill PC down in the mail room.  I understand the concept but it scares me and Flame proves my point.

Flame had this awesome (and I mean that out of professional regard for the technology – not necessarily it’s purpose) method of spreading to other PCs.  Flame leveraged Windows’ default behavior of automatic discovery of web proxy and posed as a proxy server.  Any PC within the same broadcast NetBIOS namespace with default settings would graciously start routing web requests through a Flame infected PC.  That inturn allowed Flame to intercept requests to the Windows Update service by PC’s configured to connect directly to Microsoft for Windows Updates.  In an ironic twist of fate PCs were compromised by their efforts to remain secure.  Anyway, Flame intercepted those update requests and through a fairly amazing feat of cryptography sent back bogus security patches which the PCs willingly installed because they passed validation intended to ensure they were signed by Microsoft.  And thus Flame spread to more PCs. 

My point the attackers only needed to infect a single system belonging to a low-level user and they had a chance to infect other, so-called “high-value” systems assigned to users with access to the information they wanted.  So you can’t just protect your important systems because, well, they’re all important.

Every setting matters

The above infection vector worked because of 2 obcure settings that pretty much no one but an extremely paronoid infosecurity pro would have worried about.  First, the hash algorith used to sign certicates for Terminal Services Client Access Licenses which was MD5 instead of SHA1?  The basic MD5 weakness that Flame’s authors exploited had been published a long time ago but who cared?  After all, certificates issued by that CA were only used to sign licensing certificates.  It was unlikely that anyone would want to steal some TS CALs badly enough that they would go to the trouble and computing expense required to effect a chosen-prefix collision attack on the MD5 based signatures of those certificates.  Furthermore it was only a risk to Microsoft not to their customers.  Right?  Not so much.  Turns that the certificate authority used for TS licenses had the same root CA as the CA used for signing Windows patches; and the Windows Update client gladly accepted certificates signed (or seemly so) by the TS Licensing CA.  Multiple mistakes were made by Microsoft but one of them was a simple setting on an insignificant Certificate Authority no one considered a “high-value” target.

The other setting was the one in Internet Explorer that defaults to automatically broadcasting a request for the local web proxy.  Disabling this setting and using one of several other centralized configuration methods for those organizations that do have a web proxy would have thwarted this particular infection vector.  Of course it would also have made life a little more difficult for folks travelling to other networks where a proxy was present but like an old system security officer I new once said, “If you can get your job done then I’m not doing mine.”

Don’t miss my core point here.  It’s not about these 2 particular security settings.  It’s about all security settings on every system and application.  There’s no way to know what the bad guys will think of next.  Ergo, everything matters.

Every security technology matters

Security vendors would probably pay me to say that but it’s the truth.  There are definitely a lot of “one-off” security products that come along that have little value but are designed to exploit all the hype of concerns like cloud security and mobile device risks.  Those are both areas that are perilous but a lot of products aren’t real solutions yet.  But in the area of endpoint security, there are so many threat vectors and they all need to be addressed.  Again, Flame proves my point.  First, patch management.  Organizations who were centrally managing patch deployment sidestepped the infection vector described above.  Second, configuration management.  Guess what the very first setting in the United States Government Configuration Baseline for Internet Explorer is?  “Disable changing Automatic Configuration settings.”  Why?  “To prevent machines from automatically acquiring proxy server settings from malicious servers.”  Nuff said.  Third, removal storage control.  Flame had built-in logic for spreading via USB storage devices.  Fourth, device and port control.  Flame could exfiltrate data via Bluetooth and infected smart phones.  Fifth, good ole antimalware.  Flame specifically looked for the presense of common AV products and if detected refrained from certain actions that would trigger the behavior analysis logic of those products.  Sixth, application whitelisting.  Today’s intelligent whitelisting enables you to limit what runs on endpoints to programs you have reason to trust – without creating a management nightmare.  Effective application whitelisting would have stopped initial infections of Flame cold in its tracks.

So, that’s why I say everthing matters and why you have to do everything right.  Because the bad guys are capable of anything and they are trying everything.

I’ll be presenting a session entitled “Everything Matters: Every Setting, Every Component, Every Technology”  at SecuritySCAPE 2012 which is a really cool IT security virtual event, bringing together industry analysts, thought leaders and IT professionals into an online forum to share real-world experiences, best practices, and identify future trends and challenges that we will all face.  In addition to me you’ll hear from Neil MacDonald from Gartner Group, speakers from Aberdeen Group, Securosis, Forrester Research and security experts like Richard Stiennon.  Get the full details and sign up here: SecuritySCAPE 2012.  You might get an iPad 3, too!

Triathlon, pentathlon, just a few more days of the Summer Olympics are left but there’s one more event happening in mid-September:  Randy Franklin Smith’s Quadrathlon. 

On September 12 I will be taking on the audit logs of Microsoft’s 4 top enterprise server products: 

·         SharePoint

·         SQL Server

·         Exchange

·         Windows Servers

Yeah, it’s a quadrathlon but don’t worry, you aren’t the runner – I am and I plan to be exhausted at the end.

If you're attending Protect 2012, you can get free access. 

More information here.

Originally posted at Lumension.com

Whenever I think about detecting and defending against today’s sophisticated threats I keep coming back to the same question, “How do you distinguish legitimate activity from malicious?”. That is not an easy question to answer.

For instance, read access by an authorized user or by a zombie process running on that user’s computer looks the same in an audit log. As soon as you trying to detect anomalies – like alerting on activity at seemingly odd times of the day – you also create a stack of false positives for security analysts to wade through.

One industry in particular that I think is doing a horrible job of malicious behavior detection is the credit card industry. It’s such a hassle to buy anything online today that sometimes I wonder if it isn’t better to just take cash to a store. Anything out the “ordinary” causes your card to be locked, shipments held up and the necessity of making phone calls to customer service either at the merchant or credit card company – and who has time for that? There must be a better way.

But to find that better way you have to get imaginative and start with some crazy ideas so here’s a few for starters.

CAPTCHAs

Use CAPTCHAs internally as an added gate to keep automated malicious tools from accessing sensitive information. OK, nobody likes CAPTCHAs - I understand that. Maybe, I’m already starting down the wrong road here but think about the concept and maybe you’ll come up with a better idea. What does a CAPTCHA do? It helps provide assurance that the person accessing your system is a human and not some kind of ‘bot. So, do you have a sensitive web-based application or repository of sensitive information like SharePoint? Normal user authentication does not keep out bad guy programs running on the PC of a duly authorized user. But throwing up a CAPTCHA would stop such malware until the bad guys add CAPTCHA bypass technology or more start passing interactive sessions through zombied computers.

Split Internet Access

A long time ago I provided some training to a very secure military base. They had 2 networks (classified and de-classified) going to each PC with an A/B switch between each PC and the 2 networks. Each PC had a 2 removable hard drives. To access the Internet they’d boot on the declassified drive and select the declassified network on the A/B switch and vice-versa for classified access. There were controls in the operating system to prevent a system booted on the classified drive from communicating if they mismatched the drives and network selection. All the drives went into a safe before each worker left.

I’m not talking about doing that now. But there are other ways. Here’s one – and remember I don’t claim this will be viable for every environment out there but it will be for some and more importantly, grasp the core concept – which is to give users access to the Internet while preventing sensitive data and applications from touching the Internet. So here’s the idea: Block the majority of your user PCs from accessing the Internet. Notice I didn’t say block the users – just their PCs. How do you do that? Yes, a proxy server is a start but it’s still not good enough. Instead deliver their Internet browsing experience to them via thin-client. For instance deliver Internet Explorer to end-users as a RemoteApp running on a Remote Desktop Server. Firewall the server so that end-user PCs can only communicate via RDP. Lock down the session configuration to prevent drive sharing, etc. Now users can browse the web but none of the content they access touches their PC. At most, any malware will infect the RDS system which is firewalled off from the Internal network and can be re-imaged every night and that system.

Of course you’ll have to make exceptions for users that really need to be able download files from the Internet or run other applications that really do need to open outbound connections. And we haven’t solved the incoming email problem which is admittedly a key infiltration vector for APTs such as the one that hit RSA a while back. The biggest issue with incoming mail is how to handle attachments. Maybe mail client (e.g. Outlook) should run on the RDS as well. You could allow copy and paste between RDP sessions and the real desktop without exposing yourself to the majority of malicious content risks encountered today since most exploit malformed data structures in the file format and are only going to impact the application that directly parses the data. This method would keep malware off the user’s local desktop, it would keep the malware out of the internal network and prevent the malware from impersonating the end-user who is targeted by it.

So if you can’t actually implement either of the methods, how can you – or at least software vendors – make something similar possible? When a system encounters an access request to a resource from a user with the appropriate permissions, how can the system ensure that the request is really initiated by the user and not a zombie process running on the user’s PC? How can we allow users to access the Internet and internal applications while keeping some kind of boundary in place between the network and storage accessible to Internet applications (browsers, email clients) and internal applications? And how do we provide for exceptional applications that must bridge that boundary? Could operating system vendors add a flag to processes that insulate Internet, internal applications and hybrid applications from each other similar to the memory protection that already exists between processes or the kernel/user mode boundary? And could they build a new IPC (interprocess communication) method that allows data to safely cross this boundary in a format that precludes executable code? Or is there a better idea? I hope you have one because we need it!

Originally posted at Lumension.com

In conjunction with integrating SolarWinds Log and Event Manager (LEM) with my LOGbinder software I had an opportunity to get to know LEM and I thought I’d share some of the highlights of what I discovered.  Click here to download LEM now!

For me, the most important thing about a log management / SIEM tool is its analysis functionality.  How much built-in intelligence does it have about common event logs and how powerful are its capabilities for alerting you to important activity, reporting for compliance and adhoc research?  LEM employs my favorite SIEM feature for increasing maximizing analytical power – normalization. 

Architected for Normalization

With normalization, your SIEM vendor compiles schema of log source agnostic event types that are common to nearly any technology.  These event types include things like:

-          File operations

-          User account maintenance

-          Group membership changes

-          Configuration changes

-          Network traffic events

SolarWinds provides connectors for common log sources that understand how to translate raw events from a specific log source into their equivalent normalized event type.  For instance the screen print below shows a search based on Alert Type New Group Member (in LEM, alerts are any events of interest – that is not discarded). 

When you query for this Alert Type you will get any group membership additions from all monitored log sources.  In the example above you see a member added to a Windows local group as well as a new member added to a group in SharePoint.  That screen print really illustrates the power of normalization.  You no longer need to be an expert in every arcane log format produced within your organization.  (It’s hard enough to learn the Windows event log – much less all the other security logs found on a typical network.)

As raw events come into LEM, the appropriate connector compares the event to its alert criteria and discards unmatched events.  The remaining events are normalized into alerts.  This processing takes place in the local agent which increases efficiency since unimportant events are discarded at their source.  The normalized alerts are then fed to the central LEM manager over an encrypted connection which ensures security and audit integrity.

At the manager, alerts are processed according to the alert distribution policy.  Each alert may be dispatched to one or more of the following:

1.       Alert Correlation Engine

2.       Console for display in dashboard Widgets or in filter views

3.       Storage for future reports and analysis

Automated Response through Rules

The Event Correlation Engine is where Rules are processed.  Rules define automated responses to correlated alerts.  LEM makes it easy to define rules.  You essentially build a graphical flow chart of the rule by dragging and dropping conditions, actions and Boolean logic operators on to the rule canvas; no cryptic data entry here!

The automated responses you can select range from sending emails to your security analyst, to killing offending processes, updating a user defined list or creating an incident.  The latter 2 are particularly interesting. 

Incidents are a special kind of what I would call meta-alert in LEM.  You can define rules to trigger Incidents from any alert that should be followed up on and for which you need to document such follow up.  While LEM documentation suggests printing out a daily incident report and noting your follow up and signoff on the hardcopy, I think it would be more efficient to have the report emailed to a SharePoint document library.  In the document library you could add additional columns or workflows for documenting follow up and signoff.

User defined lists (called custom groups in LEM) allow you to compare alerts against any list of items you define.  For instance, you could create a list of privileged users and then define multiple rules that use that same list to identify activity where the actor or target is a privileged account.  Of course the disadvantage of such lists would be the burden of keeping them up to date.  That’s where the user defined list actions come in so handy.  You can automate the maintenance of user defined lists! 

For instance you could create a rule for new group member alerts where the group is Administrators, Domain Admins or Enterprise Admins.  Then set a response action that adds the new member’s name to a Privileged Accounts list and a rule to handle the opposite case where a user is removed.  Of course to handle nested groups you’d need to handle some additional logic but a couple additional rules for maintaining an Admin-Equivalent Groups list would do the job.

Interactive Analysis

The LEM console provides three levels of interactive analysis.  Starting on the Ops Center tab (see below) you have a pane of customizable dashboards called widgets. 

A Widget is a visualization (e.g. simple table or a pie/bar/line chart) combined with a filter that controls which alerts are represented in the Widget.  This makes it easy to define key security indicators and keep an at-a-glance eye on them.  You can drill down into a Widget which takes you to the next level of analysis – the Monitor tab (see below). 

The monitor tab allows you to select a filter which displays on the right, the alerts matching that filter.  Then when you select an alert, its details are displayed on the bottom pane.  When you enter the Monitor tab via a Widget drilldown back on the Ops Center tab, LEM automatically selects the same filter as the Widget you just came from making it easy to see the activity behind the Widget.

You can select any data value in the Alert’s details and select Explore which takes you to the 3^rd level of analysis – the nDepth display on the Explore tab (see very first screen print).

nDepth is a really cool way to do adhoc analysis of security log activity.  At its root, nDepth is a search application that allows you to enter search terms in a single, Google-like search field.  And then of course the matching alerts are displayed in a list underneath.  However the capabilities go far beyond that simple description.

In addition to displaying matching events as a simple list, you can choose to visualize the data in a variety of chart formats, word clouds, tree maps and more.  Whenever you change your search criteria, LEM adds your old criteria to the History list.  Whenever you build a search you like and want to re-use you can save the search and it appears in the Saved Searches list.  This makes it easy and superfast to go back to recent searches or searches you knew you’d want to use again. 

nDepth provides a number of ways to make it easier to refine your search.  In the Refine Fields pane you see a list of all the field names found in the current result set.  Under each field name you find a list of all the values occurring for that field along with their count.  You can drag any of these field names or values to the search terms field and nDepth will automatically add a Boolean expression that further filters the results.

You can highlight DNS names and IP addresses and run lookups like Whois, traceroute, NSlookup.  Or you can on demand have any of the actions available to Rules described above to be executed on the manager or agent system. 

Wrapping Up

Beyond these three highly interactive and progressively deeper analysis tools, you can also schedule reports to be automatically produced and delivered via email.  LEM runs as a physical or virtual Linux appliance, the latter being easy to download and quickly set up to run in your hypervisor.  Being a Linux appliance makes it easy to setup the appliance as a separate isolated log management with access controls to prevent tampering by admins of the systems you are monitoring which is an important architectural consideration if you are depending on your SIEM to provide accountability over admins.  And though it’s a Linux system, you don’t really need to be a Linux guru because the appliance can be almost completely managed via the desktop console which runs on your workstation.

SolarWinds hosts an active user community called Thwack where you can exchange filter, report and rule content, request new features, keep up with new developments and get help from SolarWinds and community members.

SolarWinds Log and Event Manager is a capable SIEM software solution that incorporates my favorite SIEM feature – normalization.  The interface is highly visual with very few instances where you must enter cryptic text and codes.

You can download a trial of LEM from

http://www.ultimatewindowssecurity.com/redir.aspx?name=sw_reg