* Fundamentals of IT Assurance and Audit—Revised for 2009, this course is aligned with the Certified Information Systems Auditor (CISA) job practice areas, and will discuss controls and control objectives tailored to the evolving role of IT auditors, including an understanding of organizational risks and how to mitigate them.
* IT Assurance and Audit Practices—Also revised and aligned with the CISA job practice areas, this course teaches participants how to develop a risk assessment process and audit program.
* Information Security Management—This course aligns with the five Certified Information Security Manager (CISM) job practice areas and provides IT security managers the expertise needed to reduce risk and to protect the enterprise.

“ISACA Training Week provides information security managers, IT auditors and IT governance professionals with the expertise they need to reduce risk, protect their enterprise and develop strategies for IT governance in this challenging economic climate,” said Lynn Lawton, CISA, FBCS, CITP, FCA, FIIA, international president of ISACA. “It also offers a solid foundation and is another tool for those preparing for the CISA, CISM and CGEIT examinations, which are globally respected by employers worldwide.”

Instructors at the Nashville event include Al Marcella, Jr., CISA, president of Business Automation Consultants, Don Caniglia, CISA, CISM, audit consultant with Campbell & Associates; and John Tannahill, CISM, management consultant specializing in information security and audit services.
Who ISACA
What ISACA Training Week
When 6-10 April 2009
Where Loews Vanderbilt Hotel, Nashville, Tennessee, USA

The ISACA Training Week registration fee, which includes course materials, is US $2,295 for ISACA members and US $2,495 for nonmembers. Participants are eligible to earn up to 38 continuing professional education (CPE) hours.

The new research, sponsored by the Computer Security Institute, The Institute of Internal Auditors, Protiviti, ISACA, IT Governance Institute, and Symantec Corp. (NASDAQ: SYMC) outlines a risk-based approach to budgeting for information security that rewards results; the practices responsible for managing business and financial risks from the use of IT; and the substantial reductions in spending on audit in IT.

“Like an insurance deductible, all organizations are willing to sustain some level of financial risk and loss from theft of customer data or some level of business downtime from IT disruptions,” said Jim Hurley, managing director of IT PCG and principal research manager at Symantec. “However, the research findings show that an organization’s loss-tolerance is exceedingly low, and the financial returns for small improvements are extraordinarily high.”
Top Business Risks
Firms ranked three business risks from IT well ahead of other possible risks: Confidentiality of sensitive information; Integrity of information, assets and controls in IT; and Availability of IT services. The IT PCG report leverages ongoing benchmarks to measure the performance of firms against these three risk areas. The results of the benchmark surveys can be broken up as follows:

* Worst Outcomes: 19 percent of all firms are experiencing more than 15 losses or thefts of data each year, 80 or more hours of business downtime from IT failures, and more than 15 audit-failing deficiencies.
* Normative Outcomes: 68 percent of all firms are operating at ‘normal’ levels experiencing between 3-15 losses or thefts of data each year, between 7-79 hours of business downtime from IT failures, and between 3-15 audit-failing deficiencies.
* Best Outcomes: 13 percent of all firms are achieving the best results, experiencing fewer than 3 losses or thefts of sensitive information each year, less than 7 hours of business downtime, and fewer than 3 audit-failing deficiencies. The financial returns among these organizations range from 22 percent to more than 3,000 percent annually.

Surprisingly, the difference in outcome between the worst performers and the best performers was not as a result of the size of security budgets. In fact, the differences in size of security budgets were negligible. What mattered was how those budgets were used.

The new report details the following five practices being leveraged by those with the best outcomes and the least financial losses:

1. Leveraging a senior management team to manage risk
2. Prioritizing risks, improving controls, and automating procedures
3. Continuously assessing controls and risks
4. Leveraging technical controls, policies, and IT change management
5. Comprehensive reporting

Financial Implications
The financial ramifications of these risks were found to correspond almost entirely with the practices implemented by IT to manage the exposure to them. Not surprisingly, firms leveraging the best practices experience the least expensive and most infrequent financial losses. Firms operating at the worst levels paid the price, literally, with data loss and theft equaling 9.6 percent of annual revenue and business downtime costs equaling nearly 3 percent of annual revenue.

Among organizations with $5 billion in revenue, the combined costs from data loss or theft and business downtime ranged from $329 million for firms with the worst practices to $2.25 million for firms who had implemented the best practices – 149 times less.

“Firms can either wait until an emergency pushes them to reprioritize, or they can decide that it is in their best interests to institute these industry proven practices,” said Hurley.

The research found that firms with the best outcomes were actually spending between 35 and 52 percent less on audit fees and expenses. For these firms, adjusting the amount of money spent on practices that reduce risk, loss and audit spending can produce financial returns ranging from 1,000 to 500,000 percent more than the loss which the organizations are willing to sustain.

Quotes from ITPCG Member Organizations
“This report is a clear demonstration of the benefits that organizations can achieve from effective management of security, availability and other IT-related business risks,” said Brian Barnier, member of the IT Governance Institute’s Risk IT Task Force. “Good practices such as the freely downloadable COBIT framework can help organizations take specific actions to mitigate risk and maximize value.”

“As the IT Policy Compliance Group’s research demonstrates, companies that make improvements in managing their IT security risk will realize numerous benefits, including lower financial exposure and losses as well as savings on regulatory audit fees and expenses,” said Rocco Grillo, a managing director in Protiviti’s Information Security & Data Privacy practice. “The group’s findings quantify what has been assumed to be a best practice: organizations with a top-down approach and a clear owner who has line of authority and visibility to the business lines maintain the most cost-effective and comprehensive information security programs.”

Much as I wish it were otherwise, it doesn’t seem likely that everybody in the world will forsake their unnecessarily HTML-laden ways when it comes to composing emails, not only because many modern email clients default to HTML-formatted e-mails, but also because many people get deeply involved in choosing the right “stationery” background image, fancy fonts, and other pointless frippery when sending intensely interesting and highly informative e-mails like “yo, whats up? how r u?”. Luckily, a lot of those clients do “the right thing” when composing HTML emails, which is to offer a plain text version as well without the person composing the email even having to know about it.

Sometimes, however, we don’t get plain text versions along with the tangle of spaghetti HTML. This may be because, when certain things are done in HTML that cannot be reasonably well degraded to plain text, the email client just skips the plain text version; it may be because some Website developer doesn’t know any better when he designs the automated feedback form reply script; it may even be because someone stupidly turned off the plain text copy capability. It may also simply be the fact that someone is using a particularly low-quality email client that only offers HTML formatted functionality.

Regardless of how it happens, the fact remains that sometimes we just need to be able to sift through the contents of an HTML-formatted e-mail, and probably don’t want to have to do it without getting a headache. The choices are usually limited to:

1. give up on secure practices and just view the rendered HTML e-mail somehow — either within an HTML-capable email client or by viewing the email in an outside application that renders HTML
2. live with the inconvenience of parsing all that markup by eye
3. delete the offending email and request another copy without the unnecessary markup scattered through it

I used to run with number 2 all the time. After a while, I decided to write a simple script I call stripmark that would parse HTML out of the email so I could just view the plain text. Over time, it has acquired a few more capabilities, including translating linebreak tags into actual newline characters in the plain text output. This sort of thing is relatively easy to do, with tools like the Ruby programming language and a highly functional text-mode mail user agent such as Mutt. This, however, is far outside the range of what the average user is able to do, and isn’t exactly within the range of what most technically oriented people are willing to do — especially those whose tools are mostly limited to the MS Windows platform.

The script I use is gradually changing into something akin to the opposite of what text parsing libraries like Markdown do. Such libraries define a simplified markup language that is much easier to use to describe how text formatting should be specified via the keyboard, then parse text formatted in that manner, translating the document into an HTML or XHTML formatted document. In fact, I type these articles in plain text files using Vim, entering Markdown formatting signifiers by hand, then run a script that uses a Markdown library to transform the text formatting signifiers into Web markup before it gets published here at TechRepublic.

If it keeps evolving to that point, my stripmark script will eventually do the inverse: it will translate HTML or XHTML formatted documents into text with simple text formatting signifiers that make emphasis, linebreaks, and other simplified “rich text” characteristics obvious without making the text nigh-unreadable the way an actual Web markup language does.

At the moment, the script is just a dirty hack. Even if it was cleaned up, prettied up, and made worth distributing, though, its use would still be a dirty hack. What’s really needed is for mail user agents and email clients to incorporate such safety related functionality directly, either via official plugins in the case of Unix MUAs or as integrated functionality in the case of mainstream GUI email clients.

By default, a “safety mode” for any e-mail client should perform a number of tasks for the user. A few examples include:

1. Disallow embedded images, Flash objects, or anything else that isn’t actual text and markup in the rendered “rich text” email display without a warning and specific user intervention.
2. Disallow hiding URLs behind link text so that even the most casual, security-ignorant user will not be fooled into thinking a link that says “PayPal” but has a URL with a phishing.example.ru domain is a legitimate PayPal link.
3. Disallow execution of any dynamic content, especially including JavaScript, VBScript, and similar programming languages, without a warning and specific user intervention.

The list could go on at great length, but it would probably be easier to just list things that should be allowed — like italicizing text, bolding text, underlining text, manipulating colors, and physically altering the visible location of content on the screen in a manner that doesn’t hide any content (such as via tables or CSS positioning). It should also clearly indicate when any text uses characters that are not part of the standard ASCII character set, just for good measure, in case someone wants to copy and paste a URL from an email to a browser.

This, at least, would allow people like me, who are aware of the security dangers of normal HTML e-mail rendering, to view the occasional marked up email without having to go to inconvenient lengths to read it without making ourselves susceptible to the dangers of rendered HTML emails.

Unless and until such a MUA or e-mail client that I want to use lands in my lap, though, I’d appreciate it if you’d all default to sending plain text e-mails only. Considering the overwhelming tendency of spammers and phishers to use HTML e-mail, and that most legitimate email users at least offer plain text along with the HTML formatted versions of their messages (whether they know it or not), my spam filtering identifies all HTML-only emails as high-risk targets. If I don’t expect your email, and it’s HTML formatted, you should be resigned to the expectation that I may never read it.

I value my security more than unsolicited emails, and — contrary to my usual policy of avoiding false positives at any reasonable cost — I’m willing to accept a few false positives to protect myself.