Network World tries to drive home the point that you should mature your IT governance if you want to be successful in business:

The most important finding cited in this report is that “organizations with best business results are the same firms with the most mature [IT GRC] practices and the organizations with the worst business results are the same firms with the least mature [IT GRC] practices.” The key takeaway from the report is this: “The way to improve business results and reduce financial risk, loss and expense is to increase or enhance the competencies, practices and capabilities governing the use and disposition of IT resources.” In other words, you’d better practice good IT GRC if you want to have a successful company.

I am biased so it is easy for me to agree, but the devil’s advocate in me says that this could be a misleading measurement. Perhaps successful companies practice good IT GRC. It would be most interesting to examine this relationship over time.

For example, I used to think Dell quality control and ethics were top notch. The components they used, the engineering and execution of their systems, and the support they offered were unparalleled for value in the early to mid 1990s. Then they became wildly successful, and by 2000 the wheels seemed to come off their wagon. Today I just read that they have been found guilty of fraud by the New York court. My guess would be that their IT governance, just like their other processes, were stellar in the big run-up to mega-success. Then management went awry and now they are still wildly successful, but if their governance of IT is anything like their current customer support or their engineering…see what I mean?

The PC Pro: News reports that a man stands accused of trying to create fake user accounts in order to accumulate money from “tiny” payments:

According to court documents, Californian Michael Largent used an automated script to open 58,000 such accounts, collecting many thousands of these small payments into a few personal bank accounts.

Largent also performed the same trick with Google’s Checkout service, cashing more than $8,000 alone from the service.

That is fairly common, in terms of fraud and new-user creation, but here is the newsworthy part.

When the bank asked Largent about the thousands of small transfers, he told them that he’d read Google’s terms of service, and that it didn’t prohibit multiple e-mail addresses and accounts. “He stated he needed the money to pay off debts and stated that this was one way to earn money, by setting up multiple accounts having Google submit the two small deposits.”

False data is at the heart of fraud, so I am not sure why he thought that generating false names and addresses would be considered kosher. Could he not have generated aliases for himself rather than completely fake names? Aside from this inconvenient fact that he created bogus data to intentionally mislead/misrepresent himself and get money from others for it, I find it interesting that the bank was suspicious of scripts that generate funds through accumulating small fees.

According to the government, Largent was undone by the USA Patriot Act’s requirement that financial firms verify the identity of their customers. Schwab.com was notified in January that more than 5,000 online accounts had been opened with bogus information. When the Secret Service investigated, they found some 11,385 Schwab accounts were opened under the name “Speed Apex” from the same five IP addresses, all of them tracing back to Largent’s internet service from AT&T.

So the USA Patriot Act is used to mop up for some financial firms with weak controls on their website. Who notified Schwab? You would think Schwab could detect 11,385 accounts under the same name, unless that really is not a violation of their terms and an individual is allowed to setup an unlimited number of accounts. But this just takes me back to the question of why Largent bothered with fake names instead of an alias or screen name, so to speak.

Q: As an IT administrator, I’m often considering how to make the most of all security solutions that my organization needs to run smoothly, especially given the cost of compliance solutions. One item I’d like feedback on is how I can leverage the log-management product I’ve bought for compliance to protect the network against insider threats as well. If I have a log management solution in place, will that be sufficient to protect my sensitive data? What other best practices are there, and can you provide a few real-world examples?

A: Information security tools are often split into two categories – detective and preventive. The latter should help prevent attacks, as the name implies, while the former gives ways to monitor and find security events. Log management is a detective control only, so it is not sufficient on its own to protect sensitive data. You still need things like access controls and authentication to prevent unauthorized access and stop attacks. However, detective controls significantly enhance preventive controls because they warn of impending attacks (e.g., suspicious activity and surveillance) and alert you to attacks even if they are failing. Log management therefore has both direct and indirect applications that will help with compliance as well as insider attacks.

A direct method of log management usually involves collection of known logs into a centralized and secure space with long-term retention capabilities to satisfy requirements like “Secure and Central Log Collection” (PCI Requirement 10.5). Indirect methods can involve anything related to monitoring or auditing activities. This means everything from authentication and authorization to encryption to change management could benefit from log management. File Integrity Monitoring, for example (PCI Requirements 10.2.2, 10.5.5 and 11.5), depends on a log management back-end. Some may be surprised that virtually all encryption has a significant log-management component, but monitoring access and change related to keys and signatures is essential to good encryption management. Take, for example, an insider who modifies or replaces a key. Even the reverse can be important; a key that has not been rotated in a timely fashion (some rotations are meant to happen weekly) indicates a potential exposure or suspicious activity.

Best practices involve the following decisions in both planning and implementing your logging solution to meet compliance objectives:

1) Data should be normalized yet allow generation of daily summary reports for specific roles. This enables data centralization without loss of the ability to manage the details of the data at a localized and granular level. Normalization should be done with regard to long-term archiving and later review as well.

2) Specific security events should be flagged with real-time alerts, which are sent to incident responders. Compliance requirements have various terms such as “compromise,” “suspicious activity,” and “red flags,” but they all emphasize the need to both stop and document unauthorized access to sensitive data. Specific security events will depend on your business model and data, but the typical things to watch for are unusual changes to regular patterns. These often are considered evidence of fraud.

3) Make log management part of the business decision. When sensitive data is spread out, the cost of protecting it is much higher and the complexity of logging and monitoring also escalates. Is there a more efficient and therefore more secure approach to doing business? Will the cost of consolidating all the logs from various systems cost more than consolidating the systems to be logged?

A log management solution can significantly enhance an environment in both prevention and detection of attacks, helping you both achieve compliance and protect the network against insider threats.

This appeared on Network World’s Insider Threat Opinion Column