IRS Exempt from Security?

It’s TAX TIME! or is it HACK TIME?

It comes as no surprise an organization as large as the IRS is lacking some security controls, but from the material provided in several news articles it appears the IRS is lacking some fundamental elements or the application of Security Policies and standard IT Management processes is spotty at best. This is a major issue given recent news that sensitive information for the Democratic and Republican Presidential candidates was leaked by contractors.

The report findings about the IRS are items that most other organization are apparently already required to meet, according to various sources: the Sarbanes-Oxley legislation, the Payment Card Industry’s Digital Secrity Standards, and even the Health Information Portability and Administration Act. 

Overall security for an organization is made up of the sum total of all the piece, parts, polices, and process surrounding the organization. For the IRS, security seems less than what it should be. Specifically of concern are the following passages in the article, which were likely quoted directly from a report provided to the AP:

• [MSNBC] … system administrations circumvented authentication controls by setting up 34 unauthorized accounts that appeared to be shared-use accounts, the report found
• [CNN.com] more than 84 percent of the 5.2 million occasions that employees accessed a system to administer and configure routers, they used “accounts” that were not properly authorized
• [MSNBC] A review found that the IRS had authorized 374 accounts for employees and contractors that could be used to perform system administration duties. But of those, 141 either had expired authorizations or had never been properly authorized.
• [CNN.com] … there was no record that 55 employee and contractor accounts had ever been authorized.
• [CNN.com] In addition, nine accounts were still active, even though the employees and contractors had not accessed the system for more than 90 days, the report says.
• [CNN.com] The report does not say whether taxpayer information was misused, but says it is continuing to review security to see whether changes made to the computer system were appropriate or warranted.

Unauthorized accounts made unknown, untracked, and potentially unauthorized changes to systems and networks at the IRS? Multiple users share the same administrative account for making changes to multiple systems? Accounts were unused and still active after 90 days of inactivity? Log reviews are not conducted?
We are talking about the Internal Revenue Service, right??

For any organization reading this thinking, we have those same issues - what’s the big deal?

1. Unauthorized accounts making potentially unauthorized changes = a potential security breach
2. Multiple users sharing administrative account access = inability to determine who made what change
3. Unused accounts still active after 90 days = even Microsoft gets this one right!
4. No Log Reviews = no proof that a breach happened, no notice that a breach is in progress, and no idea how wide spread an attack is/was

A popular statistic among security professionals is that most security incidents are caused by insiders violating security protocols, policies, or processes; percentage is over 70% of all security incidents are caused by insiders. Given the IRS’ report findings, this is again a serious issue.

The underlying problem at the IRS is likely the same problem that other businesses face, how to be secure without security getting in the way? The simple answer: Security is a mindset. Either management gets it and supports it or they don’t and authorize exceptions to policy under the guise of “Just get it done.” This “get it done” approach completes projects on-time, often avoids cost-overruns due to last minute security bolt-ons, and usually leaves system or process gaps that can be taken advantage of by disgruntled or otherwise motivated employees.

What’s the solution?

A realistic hard look at how an organization views security, how management feels about the impacts of security, and ultimatley what costs an organization is willing to pay for security. In the case of the IRS, ”The IRS issued a statement Monday saying it had “taken a number of steps to improve the control and monitoring of routers and switches.” — [MSNBC]

China + Phishing = Oakridge Breach?

China has been rumored to be behind the hacking of US infrastructure for years and now it appears they gained access to a very high profile network at Oakridge National Laboratory.

Previous news reports suggested they compromised computers and stolen information from various DoD installations, NASA networks, and various other organizations around the world.

This latest attacksounds familiar, company X is targeted and gets flooded with phishing emails then one unsuspecting user clicks the link which unlocks the door from the inside. GOTCHA! I am not sure how you say that in Chinese, but it probably sounds a lot like SCHWING!!!

Network Zoning - In the Zone

Traditional network security featured two or three zones, whether they were thought of in terms of zones or not may depend on the organization. Certainly everyone is failure with DMZ; however, modern approaches to network security don’t stop at the perimeter. This is where these new zones come in.

In the early days of network security, the consensus was: place a firewall at the external touch-points of your network with two or more network interfaces. If you ran any public services, locate them inside something called a DMZ or screened-network and restrict access to/from those devices for internal systems. 

This should sound familiar, welcome to Network Zoning. The post-modern era of network security takes this DMZ approach and marries it with the principle of trust/privacy, so that the internal network can be carved up into segments providing increased security, compartmentalization, and privacy for users, services, servers, customers, etc.

In the earlier posts I referenced the idea of grouping like-functions of an internal network by vlan and/or IP subnet. This segmenting, grouping, partitioning, or zoning works just like the DMZ approach of traditional network security with the exception that the rules for access will be different and the “firewall” is internal. Here comes the tricky part.

Implementing the segmentation part can get complicated. I recommend vlans and different IP Address ranges as a general architectural practice, but it is possible with modern technology to insert transparent firewalls (let firewalls be firewalls) to facilitate rapid firewalling of network segments without having to implement vlans and IP Addresses.

These zones form boundaries inside the network, if you implement traditional firewalls they represent layer 3 boundaries and if you implement transparent firewalls they represent layer 2 boundaries. The outside boundaries should be thought of as untrusted, DMZ-like boundaries should be untrusted or semi-trusted, and depending on the user community the internal boundaries may be trusted.

These boundaries isolate trusted, untrusted, and semi-trusted devices and services from one-another and form what is referred to as a trust boundary. Trust boundaries can then be used to form privacy boundaries, where decisions are made segment trust implied within these various segments.

Getting back to the zoning concept, one design might feature an external firewall or set of firewalls (if redundancy is preferred) that provide the first barrier between the Internet and Internal users. Assuming the organization provides DNS, Email, Web, or other publicly available services, this firewall will provide an external DMZ as well. This will create one untrusted zone and one semi-trusted zone that will interface with an internal firewall/router acting as a semi-trusted barrier (zone) where the actual trusted zone(s) live.

The firewalls in this diagram can be routers, switch routers, firewalls, or a combination. The key is selecting hardware/software that will support the particular environment and needs of the organization. Firewalls come in all flavors, colors, and sizes these days and many do more than just filtering of packets, including deep packet inspection, IDS/IPS, load balancing, malware scanning, and web content filtering. Most routers on the market today can provide packet filtering / inspection in addition to traditional routing functions with minimal performance implications.

This specific architecture addresses minimal internal and external security from a zoning perspective needed to produce a trust barrier where internal systems should be protected from external (untrusted) systems. If the Internal Servers segment is firewalled from the Corporate LAN segment in this diagram, then four (4) security zones will form a privacy boundary in addition to the trust boundary where servers are isolated from users and outsiders are isolated from insiders.

PCI: How to break the piggy bank!

For any company, merchants included, who haven’t been meeting the PCI Data Security Standards, I have some bad news: you’re about to spend at least twice the money you never spent on security and privacy in the first place.

If you purchased bargain basement discounted Point-of-Sale systems, you’re in for a surprise courtesy of Visa’s Application Securityrequirements. In fact PCI has adopted these standards and will begin enforcing them in 2008 and 2009. The requirements associated with the Application Security portion will target all levels, not just the top tier.

If you lucked out in the PCI Compliance lottery by outsourcing everything to do with credit card data, that outsourcing is likely to get expensive as the outsourcer will likely pass those costs on to its customers.

If you seriously need to get up to speed quickly, I would advise following the steps outlined in a recent SearchSecurity Article. I’ve numbered the steps as Mike Rothman presented them in the article:

1. First, pick off the low-hanging fruit such as Requirement 1, which is to have a firewall to protect cardholder data, and Requirement 5, which mandates the use and updating of antivirus software.
2. Requirement 2, which is to change default passwords and other security parameters.
3. Also take a look at Requirement 4, which requires encryption to protect cardholder data that is sent over open networks. Simply using SSL allows an organization to check the box on that requirement.
4. After picking off the simplest stuff, address the requirements that can be difficult or nebulous, like Requirement 3 to protect stored cardholder data, or Requirement 6 to develop and maintain secure systems and applications.

The last thing you want to do is try PCI Compliance blind-folded. You and/or your team need to understand the requirements before you attempt to comply and before you bring in any outside consultant to document data flows or perform site assessments because it is easy to go broke and/or break the company complying with PCI.

PCI Ramblings

Practicing security is not the art it use to be. I read an article on Ambersail’s blog that reminded me of the youth soccer team I used to coach.

In particular, I was struck by the similarity between people’s attitude towards security, and a group of kids playing football. Somebody kicks the ball, and the other 21 players chase after it. No strategy, no gameplan, no big picture. Everyone likes to think they have the answer (me included, of course) and that’s what they pitch in with. But in the end, it’s just a single kick - and off we all go again, chasing the ball. [Ambersail Blog]

The post was in response to the Fasthost breach, reported in The Register, but what stuck me as I read the Ambersail post was just how true the point was and how the 7-8 year old soccer kids I coached a few years back all blindly followed that soccer ball around and would rarely get in front of it to stop the ball. Comments and suggestions can be helpful after a breach but they’re more powerful BEFORE the breach.

It’s been said hindsight is 20/20; security is no different. What should and shouldn’t be done from a security perspective becomes painfully clear after a breach happens. The same is true for almost any operational environment where something has gone amiss.

Rarely are there huge “Ah hah!” moments in our day and age, where the lessons learned following an incident or breach are new discoveries. I’ve said it before, the security landscape ends up being the sum of the compromises and consessions a company makes.

Most often the very things that lead to breaches, compromises, or even operational failures are the result of business decisions made in order to reduce cost, lower support impacts, be user firendly, or reduce operational burdens associated with observing appropriate security and privacy controls. Obviously this doesn’t account for 100% of security breaches, but certainly more than half of reported breaches could have been prevented by proper security controls.

This is one reason why security requirements are showing up everywhere and another reason why, just like my soccer kids, everyone will continue chasing the ball no matter where it goes and breaches will continue until someone gets in front of the ball!

Regulatory Flaws

I learned many things working for an former DOJ attorney but the thing that stands out the most is his savvy when it came to predicting what organizations would do in given situations. Legal regulations and contracts produce the same effect in businesses: do the minimum to get by aka comply.

Doing only what you have to, will catch up to you in one form or another. This minimalist philosophy is infectious. Take for example the rampant security breaches of the 21st century. Hackers unite!

Companies of all size grow and extend their business in order to satisfy their customers. If the company is publicly traded, then the company also seeks to please its stockholders. If security was a priority, companies would solve the data breach problem voluntarily. There are any number of reasons for security being what it is today.

We don’t need regulations in order to promote and achieve security within organizations, rather courage and leadership are needed. Security is not a profit-center, it is risk-avoidance; just like insurance. No one buys insurance (except maybe Allstate’s insurance) expecting to make money, insurance protects you against loss [whatever form that loss may take] but the insurance is only as good as the language in the policy. Security is no different; however, a company can reduce the cost and improve the effectiveness of security by including it throughout the organization and by building it into products and services instead of adding it on after a data breach has occurred. Unfortunately, too often security is implemented in the form of damage control following an incident because little financial justification can be made in advance of such an incident.

Regardless, politicians’ calls for “stronger” regulation are predictable because “stronger” regulation is “better”—in a press conference. In the real world, however, regulation is no more capable of divining threats to data security than, say, a common law liability regime, or even businesses’ natural interest in maintaining their operations, integrity, image, brand, and assets. [CATO]

Businesses will stay ahead of both the law and law breakers if strategy, business processes, and the big picture replace procedural band-aids, reactionary planning, and cost as their chief motivators. [ITCI]

If all that fails, you can still buy insurance!

Log Management 101

If you are in any way involved with technology, you have at one time or another dealt with logging. You either didn’t have what you needed, spent hours looking a needle in the haystack, or had to go find someone to help you get what you needed.

In networking and security circles, logging is usually a hot-button topic. I’ve spent many man-months working with logs, investigating logging solutions, praying to God for a solution to logging, tweaking open-source logging programs, and discussing logging technology with various vendors. I’ve collected some of the more relevant articles on the topic and have some additional commentary / insight.

First and foremost, the primary problem of Log Management is often not the log(ging) portion - most systems spew limitless log data - the problem is the management of the log(ged) data. You’ve heard 1000 times, management styles vary by manager. Management of network, servers, and security differ wildly. Networks and servers are managed by exception, they get attention when they need it otherwise they just purr and no one bothers them (until Patch Tuesday or until Cisco has a bad day). Managing security is altogether different, because security for a given organization is the net sum of all the parts of said organization, and in order to properly manage security, information from all the parts must be reviewed on a routine basis.

This routine review of information is where the problem comes in and it is why nearly every regulation, guideline, or contract stipulation (read PCI DSS) has mandatory language about reviewing logs. Again there is seldom anything about requiring systems to output logs, because that is rarely the problem. Technology is often times misapplied in attempts solve human-created problems, log management is an ideal instance for technology to come to our rescue. How else would a sane person cull through gigabytes or terabytes of log data from ten’s or hundred’s of systems or network elements? <Don’t answer that question, I’ve done it myself .>

Logging resources

• Anton Chuvakin’s Security Warrior Blog
• Network Systems Design Line: Security Event Correlation Article
• GEEK Speek Blog: Dealing with Logs
• TaoSecurity: Log Mgmt Summit
• SANS Reading Room: Logging Technology / Techniques

Dealing with the actual logs and delving into whether you want to collect log data, consolidate the log data, correlate log data, and or perform event management usher in the next set of issues / challenges when dealing with logging. Originally logs might have been aggregated onto one server or they might have been aggregated by log severity using syslog-ng or syslogd. Network or systems management systems (CiscoWorks or HP OpenView) might have received logs and performed parsing or filtering on key events that drove alerts and alarms but these systems likely discarded the log data itself, so investigating the root cause of an alert or incident became next to impossible.

Compliance came to the scene and brought innovation in log collection and log management; software became available to manage logs from multiple sources but you had to pick your poison: Windows with MS SQL back-end, Solaris or HP-UX with Oracle, or Linux and MySQL. Aggregation and consolidation were solved by tiered deployments and agents were usually installed to siphon off Windows Event Data. Security hit the mainstream and event correlation was the big buzz word.

The problem was how the intensive resources necessary to store the log data competed with the intensive resources necessary to correlate dissimilar log formats to produce alerts or suppress logged events. Gartner and others coined the the term SIEM, which combined log collection and event correlation, and a new market arrived. Most SIEM (SIM, then SEM, finally SIEM) are really good at the collection piece (historical) or really good at the correlation (real-time) piece, while few are good at both. Go, go Magic Quad. rant! If you hadn’t already noticed, I’m not a fan of combining these technologies (I don’t mix my food while I’m eating either). I like my logging solution to have plenty of evidence preservation goodness and I don’t want it muddied because a correlator had to normalize the data before it could parse, alarm on, or display the log data.

Some of the options for solving log management challenges

• LogRhythm
• LogLogic
• ArcSight
• Splunk
• Got a PIX?
• Yummy Kiwi
• Collection of Log options

Just scratching the surface, more please?

Network Zoning (Parallel Dimensions)

Further expanding on the Zone concept, I created another diagram to demonstrate the layering that will be accomplished when the zones are implemented.

In effect, the ZONE-NETCORE becomes the underlying fabric that enables the other zones, in this series.

You certainly don’t need to secure your zones in this way and you can definitely just trunk your ZONES back to a firewall or router or a cluster of either, as indicated in this diagram. You can combine this diagram with the other and create clusters of zones, if you choose.

Trust becomes the deciding factor in the approach you take to zoning, followed by comfort with and understanding of the nuances of trunking versus routing. Often times, the idea that multiple zones are traversing the same physical link with only logical (software) separation is enough to drive implementations towards a routed model.

iPhone: Cracking the Dream

Moore is the man. I have lost count of the number of times I have uttered those words. I am a huge fan of Metasploit and the framework it provides is unrivaled. I recently wrote about the hacking platform that an iPhone provides, noting it would be a great tool for a bad guy. Moore is a man on a mission…

HDM has an updated ARM hack that promises to take over all iPhones, but for now takes over modified iPhones. Techie speak here, English here.

We can store our shellcode at offset 0×12C and patch the return value with 0×0006b400 + 0xA4 to return back to it. A quick test, by setting offset 0×12C to 0xffffffff (an invalid instruction), demonstrates that this works. We have successfully exploited the iPhone libtiff vulnerability using a return-to-libc back to memcpy().

Modified iPhones make this stack/heap overflow easier to accomplish, while “native” iPhones require some additional manipulation to consistently produce the exploit.

This attack exploits libtiff (TIFF Image Library in OS X) by writing to the stack a memory location that is writable and then execute that code (gross oversimplification). The manner in which this exploit is delivered opens the door for other exploits and shows how research to “modify” the iPhone for freedom from AT&T can be used to 0wn the iPhone!

Metasploit continues to be a great tool for “evaluating” security of just about anything:

While using a hex editor to write this exploit is possible, the Metasploit Framework provides a much easier method of testing different contents for the TIFF file. A working exploit for this flaw (successfully tested on 1.00 and 1.02 firmwares) can be found in the development version of the Metasploit Framework (available via Subversion).

Governator Terminates Data Protection Law

I love the Terminator movies, Arnold is great in them. (No flames please!)

He apparently has some savvy advisers who have flexed their political and technical muscle in a way similar to Arnold’s physical: see Governor Kills California Data Protection Law. I find this line of logic amazing, especially given that Arnold is supposed to be some dumb jock elected Governor of California:

However, the current version of the bill, Schwarzenegger said, “attempts to legislate in an area where the marketplace has already assigned responsibilities and liabilities that provide for the protection of consumers. In addition, the Payment Card Industry has already established minimum data security standards when storing, processing, or transmitting credit or debit cardholder information.”

The governor argued that “the industry”—presumably a reference to credit card companies and the PCI Council—is in a better position to know what is realistic and reasonable for credit card security.” Also, he said, signing such a bill could actually create a conflict.

“This industry has the contractual ability to mandate the use of these standards, and is in a superior position to ensure that these standards keep up with changes in technology and the marketplace,” he said. “This measure creates the potential for California law to be in conflict with private sector data security standards.”   –eWeek / Security Focus

I know security experts that couldn’t come up with the logic behind that statement. I’m not a fan of legislating everything and I think what the Payment Card Industry is doing with Data Security is great, if significantly late to the game.

The major problem I have with the PCI DSS requirements is the subjectiveness of assessment, audit, and enforcement. If the PCI DSS actually had teeth, then the breaches we read about would be less likely to occur because of the financial impact associated, For instance, when a merchant can’t process credit cards due to noncompliance with the PCI DSS, they would signficantly more interested in complying with PCI DSS.

Go Arnold!!!