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]

PIX Logging Architecture is Back Online

Great news, after a brief recess, PIX Logging Architecture is back on the NET!

Be sure to checkout the screenshots for features / selling points and import the latest syslog-message database if you’ve not done that since installation. Remember PLA handles the following Cisco Security Devices:

PIX Logging Architecture v2.00 supports log messages from the following devices:

• Cisco ASA (TESTED AND CONFIRMED)
• Cisco PIX v6.x (TESTED AND CONFIRMED)
• Cisco PIX v7.x (TESTED AND CONFIRMED)
• Cisco FWSM 2.x (TESTED AND CONFIRMED)
• Cisco FWSM 3.x (TESTED AND CONFIRMED)

PLA Documentation

PLA Screenshots and more PLA Screenshots

PLA: Latest PLA syslog message support

Support for alternate forms of syslog daemons can also be found here for parsing rsyslog.

Welcome back Kris!

Tweaking PLA: Using rsyslog

[BetterTechInfo has an thorough PLA Syslog Configuration article now]

PLA (PIX Logging Architecture) uses regular expressions (regex) to parse syslog messages received from Cisco firewallsand comes pre-configured to process standard “syslogd” message format. Most current Linux distributions ship with rsyslog (able to log directly to MySQL) while some administrators prefer syslog-ng.

The installation documentation distributed with PLA assumes a familiarity regex, so here you’ll see how to tweak PLA to parse your rsyslogd log file.

Perl is used to parse through the syslog message looking for matches to message formats described in the syslog_messages table in the pix database. The processing script pla_parsedcontains a regex pattern that must be matched in order for the processing to occur. The applicable section is:

### PIX Firewall Logs
### DEFINE YOUR SYSLOG LAYOUT HERE!
###$regex_log_begin = “(.*):(.*) (.*) (.*) (.*) (.*) (.*)“;
$var_pixhost=3;
$var_pixmonth=4;
$var_pixdate=5;
$var_pixyear=6;
$var_pixtime=7;

Here, the variable regex_log_beginneeds to match up all the log information up to the PIX, ASA, or FWSM message code in order to understand date, time, and host for these messages. Take a look at the provided sample log entry, everything in red needs to be picked up by regex_log_begin while the remainder is standard for Cisco firewalls:

Oct 21 23:59:23 fwext-dmz-01 Oct 21 2006 23:58:23: %PIX-6-305011: Built dynamic TCP translation from inside:1.1.1.1/2244 to outside:2.2.2.2/3387

Explaining the operation of regex and wildcards is beyond the scope of this article; however, numerous guides have been written to fill the void. In our case, adjusting the default regex to match rsyslog is straight forward after noting which characters match which pattern, again we’re working with the basics of regex here - nothing fancy.

Take this sample rsyslog entry and notice the difference from the standard syslogd format:

Feb 21 10:59:32 Feb 21 2008 10:59:32 pix4us : %PIX-6-110001: No route to 1.1.1.1 from 3.4.5.6

Feb 21 10:59:32 Feb 21 2008 10:59:32 pix4us
Oct 21 23:59:23 fwext-dmz-01 Oct 21 2006 23:58:23

Here, the rsyslog entry includes the date twice and then the hostname of the log source versus the default format expected by pla_parsedof date hostname date. The original regex is set to pickup the first time entry’s “minutes and seconds” and picks up the next 5 words/entries separated by spaces:

$regex_log_begin = “(.*):(.*) (.*) (.*) (.*) (.*) (.*)“;

 Oct 21 23:59:23 fwext-dmz-01 Oct 21 2006 23:58:23

In order to process rsyslog, this will have to be changed. The initial (.*):(.*) is used to set a starting point in syslog message string. Since this new rsyslog format includes two date entries before the host name, the following can be used to allow pla_parsedto “see” the new syslog message string:

$regex_log_begin = “(.*):(.*) (.*) (.*) (.*) ((.*):(.*):(.*)) (.*)“;

Feb 21 10:59:32 Feb 21 2008 10:59:32 pix4us

The regex starts out the same, but looking at the colors you will notice the location of the information needed by pla_parsed to determine date, time, and host has moved. This time we used “(.*):(.*)” and “((.*):(.*):(.*))” to force a match on the time elements.

As a result of this change, the variables listed below the regex pattern must be modified to tell pla_parsed which (.*) contains which element:

$regex_log_begin = “(.*):(.*) (.*) (.*) (.*) ((.*):(.*):(.*)) (.*)“;

$var_pixhost=7;
$var_pixmonth=3;
$var_pixdate=4;
$var_pixyear=5;
$var_pixtime=6;

The numbering happens left to right and the color coding should help this make sense. The ()’s around the grey time entry are grouped together and count as one match/entity, the sixth variable. This same approach of keying off the timestamping can be applied to pla_parsedin order to allow processing of syslog-ng, ksyslogd, or any other syslog message format.

Need help with a different format? Have problems getting your PIX logs loaded? Paste in a sample message from your syslog server (IP Addresses santized please) in a comment below.

PLA: Setting up the Database

Updated installation documentation for PLA (PIX Logging Architecture).

If the PLA documentation leaves you looking for the DUMMIES guide, checkout my mini-article on BetterTechInfo regarding PLA Database Setup.  

I am getting involved in a new business venture and decided to publish some early projects / work to help out folks using PLA.

Be advised the construction dust is everywhere!

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!

Cisco IPS Event Viewer Database Hacking

Ever wished you get different snapshots from the Cisco IEV tool? Management ever asked what went on the last 30 days and your management platform can’t help you?

I found myself needing to provide a 30 day report from a Cisco IDSM2 blade, after finding no built-in option in the https servlet on the IDSM itself and nothing immediately available in the Event Viewer, I began to look around.

Cisco provides the freely available IPS Event Viewer (IEV) for their IPS/IDS productsthat makes use of java to load alert data into MySQL tables for display in the stand-alone software. If you want a full blown reporting engine and monitoring tool for Cisco IDS/IPS you’ll need to look at MARS and then look elsewhere. (Anyone I work with will tell you I’m not fond of CS-MARS.)

I found the MySQL Admin widget (mysqladmin.exe) and looked at the databases and tables installed by IEV. I’ve spent a fair amount of time with sql and MySQL databases, so I looked around the table structures to see if there was another option.

The database names and table names along with their configuration are viewable in the MySQLAdmin GUI. You could also do this with show commands at the mysql prompt: show databases, show tables, describe tables.

Using the field names, I constructed the following query:

select FROM_UNIXTIME(receive_time/1000,’%c-%d-%Y’) as date ,count(sig_id) as counted, sig_name from event_realtime_table group by sig_name, sig_id, date order by date, counted;

Note the receive_time and event_time fields are unix timestamped in milliseconds, not seconds. In the example above, I compensated by dividing by 1000, because I only needed calendar days.This results in the following response: 

+—————+———-+——————————————+
| date                 |counted| sig_name                                
+—————+———-+——————————————+
| 11-06-2007 |              1 | FTP Authorization Failure               
| 11-06-2007 |              1 | Storm Worm                              
| 11-06-2007 |              1 | DNS Tunneling                           
| 11-06-2007 |              2 | TCP Segment Overwrite                   
| 11-06-2007 |            44 | TCP SYN Host Sweep                      
| 11-07-2007 |               1 | SMB Remote Srvsvc Service Access Attempt
| 11-07-2007 |               1 | SSH CRC32 Overflow                      
| 11-07-2007 |               2 | MS-DOS Device Name DoS                  
| 11-07-2007 |               2 | FTP PASS Suspicious Length              
| 11-07-2007 |               3 | HTTP CONNECT Tunnel                      
+—————+———–+——————————————+

The event_realtime_table only contains the most recent data; depending on your setup this may be 1 day, 5 days, or 30 days. In my case, I only have 24 hours worth of data in the realtime table and have to look elsewhere for the prior 29 days.

If you’ve configured any archiving, you will need to tap into those extra tables in order to get the full 30 days. I elected to export all the tables to a single CSV file and do the parsing in Linux. Using the commands below, I created a file that contained the receive_time (MM/DD/YYYY), severity, sig_id, and sig_name:

tr -d ‘47′ < /tmp/exported.csv |  awk ‘{FS=”,”}{print strftime(”%x”, $6*.001)”,”$3″,”$9″,”$10}’ > file.txt

This gave me a table of dates, severity, signature id’s, and signature names that I can use as needed. From here I used awk to mangle the columns and pre-format the results for loading into Excel as a chart:

awk ‘{FS=”,”} {print $1,$2}’ /file.txt | sort -rn | uniq -c | awk ‘{print $3″,”$2″,”$1}’ | sort > excel_ready.csv

This results in a comma delimited file that can be loaded into Excel and used to create charts or graphs as needed. The commands can be scripted to run every 30 days on archived files, if necessary.

     75 09/30/07,0,3030,TCP SYN Host Sweep
      8 09/30/07,0,6250,FTP Authorization Failure
      3 09/30/07,1,2100,ICMP Network Sweep w/Echo
      4 09/30/07,1,3002,TCP SYN Port Sweep
      7 09/30/07,2,6066,DNS Tunneling
      2 09/30/07,3,1300,TCP Segment Overwrite
      3 09/30/07,3,3251,TCP Hijack Simplex Mode
      4 10/01/07,0,1204,IP Fragment Missing Initial Fragment

You could easily import other fields, the ones of most interest to me where:

• field 3         Alert Severity (0-4) [Informational - High]
• field 4         Sensor name (if you have more than one sensor)
• field 6         Timestamp epoch using milliseconds instead of seconds
• field 9         Signature ID
• field 10       Signature Name
• field 14       Attacker IP Address
• field 15       Attacker Port
• field 17       Victim IP Address
• field 18       Victim Port

About the Linux commands:

If these commands are new, or you’d like to understand more about using *nix tools to parse text, look here and hereto get started, google Linux, or go to your favorite bookstore and buy an O’Reilly book.

The tr commandused above removes the single quotes wrapped around each data element during the database export. This is done using the ascii code for the single quote character. This is necessary to perform the data formatting in the awk command.

The awk command uses several arguments to perform formatting of the data. First, the {FS} element is used to tell awk to use a comma as the field separator instead of spaces, which is the default. Once awk understands how to break up the fields, I format the receive_time field. awk sees the receive_time field as the sixth field and assigns it $6, accordingly the other field elements are addressed in the same sequential method. The print action tells awk to display the fields as output fields. I used the strftimeto convert the Unix timestamp back to human readable time. There is a caveat here: you must account for millisecond timestampingversus standard “seconds from epoch” in traditional timestamping. Each operation in awk is separated by {}’s.

I used standard sort and uniq to perform sorting and counting functions on the data I parsed using awk.

PIX Parsing (Usable Logs!)

If you have a Cisco PIX you are responsible for, don’t have a logging solution for it, or haven’t seen PLA, keep reading you’re going to be impressed. PDM is out and ASDM is an improvement but who wants to run https-server on a firewall?

There are plenty of commercial solutions available, some just perform log analysis and others attempt to perform event correlation. If you just want to solve the logging problem and are unable to implement a log collection system, take a look at PIX Logging Architecture.

I recently implemented Pix Logging Architecture (PLA) to help manage FWSM, PIX, and ASA logs. I hate having to cull through syslog files looking for traffic stats, tcp port usage, or accepted vs denied traffic information. This point and click world we live in has me spoiled, I don’t want to CLI everything - especially when I’m headed into a meeting to discuss who has access to the Oracle Applications database server.

What if you could get a daily snapshot of your firewall(s)? How about running queries instead of text-based finds? The following log messages are already supportedand reg-ex can be used to further extend the capabilities. Defining traffic types and being able to make graphs? Once you involve a database, you have to decide how often to purge the data.

If you like that and aren’t afraid of using open source, you’ll need apache, MySQL, perl (with some additional modules), syslog daemon or the syslog file, and one more Cisco PIX, ASA, or FWSMs. The OS is up to you, but Linux is highly recommended.

What is PLA?

The PIX Logging Architecture [PLA] is a free and open-source project allowing for correlation of Cisco PIX, Cisco FWSM and Cisco ASA Firewall Traffic, IDS and Informational Logs.

PIX Log message parsing is performed through the use of the PLA parsing module or PLA Msyslogd module. Centralization of the logs is provided using a MySQL database, supported by a Web-based frontend for Log Viewing, Searching, and Event Management. PIX Logging Architecture is completely coded in the Perl programming language, and uses various Perl modules including Perl::DBI and Perl::CGI.

Where is PLA?

PLA’s website has been down since late December but Kris reports it’s BACK ONLINE! If you are interested in downloading the software or documentation, you can find it on SourceForge but your best bet is to go directly to the source itself: PIX Logging Architecture.

I’m working on uploading the documentation and some tweaks to pull in Cisco IPS Event Viewer data into the IDS tab onto my other website, but haven’t been able to reach the original author (Kris) yet.  

How does PLA work?

The PLA software is divided into a parsing piece, database server, and web front-end. Depending on your security policy, network zoning, and server capabilities, you can run this on one server or spread it across several. I was fortunate enough to have access to a dual processor duo2 server, so I implemented everything on the same Linux server.

The underlying architecture is very clever. Message formats are loaded into memory and the syslog file is tailed (via perl module). Messages are flagged by type and processed accordingly, in near-real-time:

The PIX Logging Architecture parsing module, which is responsible for extracting the necessary fields from the PIX system log messages, has been extended to gather new information including, but not limited to, Translations (Xlate’s), Informative Log Messages (i.e. PIX Failover, PIX VPN Establishment, PIX Interface Up/Down, PIX PPPoE VPDN establishment and the like). All the parsing information needed by the PLA Parsing Daemon (pla_parsed) in order to extract data from the logs is now stored in the database, allowing for easy updates of the supported log messages without having to replace the parsing scripts. Moreover, the PLA Parsing Daemon runs as a daemonized Perl process in the background and reads straight and in quasi real-time from the system log files, so no more need to create crontab jobs like before and having to restart syslogd all the time.

The PLA Team has created detailed documentation for installing, tweaking, and supporting PLA. [edit: Google cache of documentation. PLA Documentation can be downloaded at SourceForge].

 In order to get started, you’ll want to read through the first few sections to get a feel for what will be required and figure out what you’ll need in your environment. For example, if you run standard syslogd the parsing of the syslog file works one way and if you run ksyslog or syslog-ng you’ll need to make adjustments. Section 5.5 of the documentation covers tweaking the regex for parsing other syslog engine formats. The documentation explains centralized installation versus distributed, as well as what ports and services will be needed on the server(s).

Security is obviously a concern when processing security log files. Securing the MySQL database access and Apache access is recommended. I would also recommend securing the server itself, if you’re new to Linux this may help.

Enjoy!

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!