5/21/2012
Aarni Heiskanen, LJK
Project portfolio management (PPM) is becoming mainstream in corporate governance. While the benefits of PPM are evident the question arises whether the same concept could be used in management at large.
Portfolio thinking has a proven versatility in the industry of management consulting and PPM tool development. The same guiding principles that make PPM so effective work in evaluating ideas and managing strategic assets.
Some years ago, when our company outlined our philosophy of portfolio management, we summarized it in the following diagram:
There are three strategic portfolios and three questions that transform the business strategy into operational reality:
- Idea portfolio—What ideas make us successful in the future?
- Project portfolio—Are we doing the right projects?
- Assets portfolio—Do our assets make our strategy possible?
All three portfolios are interconnected. Ideas turn into projects that create assets. Asset development needs generate ideas or projects. Projects can induce ideas.
Incorporating the three-portfolio model in decision-making and management processes has many benefits:
- It helps align internal development with corporate strategy.
- It creates a traceable path from the present situation into the desired state.
- It improves development efficiency by focusing on the right issues and reducing overlapping development initiatives.
- It promotes open communication about important issues.
If the company is already familiar with PPM, implementing the three-portfolio model is not necessarily a huge effort. Some of our clients have already started managing their IT assets as a portfolio that uses partly the same criteria as their projects. I believe that in the future we will see more companies moving in the same direction.
Read Aarni Heiskanen’s recent Journal article:
“Project Portfolio Management,” ISACA Journal, volume 3, 2012
5/14/2012
 Danny M. Goldberg, CISA, CGEIT, CCSA, CIA, CPA
Today I had the great honor of speaking on critical thinking at the Institute of Internal Auditors (IIA) Trinidad & Tobago Chapter. As this was my initial exposure to “international” speaking, I was a bit nervous and apprehensive. As I travel almost on a weekly basis, I never have time to enjoy the city and culture. This past weekend, I researched the area and my anticipation increased greatly.
As the day went on, I slowly bonded with the audience and broke down any perceived barriers. I was most intrigued by the language of internal auditing, which, yes, I will compare to the language of love. Bottom line is internal auditing, no matter the culture or the country.
I found it very unique that the mayor of the Port of Spain, Trinidad & Tobago, started the day out with a proclamation for the internal auditors. I have had the opportunity to meet some amazing people at many chapters over the past five years, but never have I had the lead-in speaker be the mayor! He proclaimed that week “Internal Auditor Awareness Week”! Pretty cool…
I also found that the challenges of the Trinidad & Tobago internal auditors are similar but somewhat different from those in the US, which is where I am located. We are all about adding value as internal auditors in the US, but to me, there seemed to be more of a “wall” of independence in Trinidad & Tobago. Yes, value is important, but we must also play the role of the police, to a certain extent.
We spent the day discussing critical thinking and spoke in length about the importance of interpersonal skills and listening as a major part of that. The general themes of the session were: “It is not what you say, but how you say it.” and “It is not the first question you ask, it is the next.” Most of my exercises still hit home in Trinidad & Tobago and the bottom line was: Auditing is similar to the language of love—regardless of where you are at, you can still speak the international language of internal auditing!
I could not have asked for a better experience than speaking at the IIA Trinidad & Tobago Chapter. They could not have been more hospitable to the Texas boy visiting.
Read Danny Goldberg’s recent Journal article:
“Communication the Missing Piece,” ISACA Journal, volume 3, 2012 5/7/2012
 Steve Markey
For those still pondering the relevance of nonrelational, distributed database management systems (non-RDBMS) and/or big data in the enterprise, I wanted to highlight several recent articles and announcements that have come out from the industry since I drafted my recent ISACA Journal article. SHMsoft has made a splash with announcing that they have deployed a big data solution, based on Hadoop, for e-discovery purposes. And, Cisco, EMC and VMware are now offering bundled training on the cloud and big data.
What these announcements mean is that non-RDBMS are moving quickly toward the main stream. With the advent of big data, information systems (IS) professionals have a new paradigm to deal with, but seasoned professionals have been down this road before. E-commerce platforms, anyone? By practicing the fundamentals of business case development, requirements facilitation, project management, incorporating security into the development process, privacy by design, information governance and copious testing, an organization can greatly increase its chances for a successful non-RDBMS implementation.
Once an organization successfully introduces non-RDBMS into the fray, a question may come up as to whether traditional relational database management systems (RDBMS) should be sidelined for all subsequent development projects. The answer depends on the requirements; however, I believe that most organizations will continue to use their RDBMS as needed due to the outlaid capital expenditures spent over the years. With an organization leveraging both non-RDBMS and RDBMS, another question to ponder is whether to cross-train existing IS professionals on this new technology or to have dedicated resources brought on board with this skill set.
Pending budget, I advocate that an organization provision new positions to administer and manage non-RDBMS and/or big data systems; that said, analysts, programmers, project managers and traditional RDBMS administrators (DBAs) should be cross-trained. This is all based on the needs of the business, but one could find a specialty focus within those organizations that already leverage non-RDBMS and/or big data platforms (e.g., Yahoo, Facebook).
Read Steve Markey’s recent Journal article:
“A Primer on Nonrelational, Distributed Databases for IS Professionals,” ISACA Journal, volume 3, 2012 4/30/2012
Carl A. Foerster
The focus of the information security community is most often on the protection of organizational information from the outside world. The threats could be hackers and scammers who are trying to get into your network to rob or deceive you. In keeping with this view, most preventive measures are aimed at guarding the castle walls and protecting the data flow with firewalls, a host of other techniques, and, hopefully, good employee training and vigilance.
Our research looks at another area that also requires attention: internal threats.
Within many organizations there is a need to segregate information internally—to prevent access by the organization’s internal employees to its own information. The most obvious example of this is the restriction of employee personnel information to only those people who have a justified need for access. There are other situations where core business information must also be segregated, so that those who need the information have it and those who do not need it are prevented from accessing it. This is, of course, the basis of role-based access, which essentially engineers the system permissions according to various classes of information requirements.
What are the factors behind the decisions when those permissions are developed?
That is the essence of our research: examining the underlying decision factors that are considered regarding applying controls on information in order to segregate it within the organization. In addition to examining the factors and gauging their significance, this research provides a limited look at the consequences of failures of internal segregation and the price paid for achieving this protection.
4/23/2012
Tommie W. Singleton, Ph.D., CISA, CGEIT, CITP, CPA
The first point about transfers of data is that from an IT auditor’s perspective, all data transfers have a fairly high level of inherent risk. Moving data from one database to another, one system to another or one application to another is simply a dangerous situation. Many things can go wrong with the transfer, and it is possible that errors could occur and not be recognized or identified—short of some effective mitigating control.
This fact leads to the second point: All data transfers need some kind of control to gain an acceptable level of reliance on the target data; that is, the source data are precisely the same as the target data. There are a variety of ways an effective mitigating control can be implemented.
A key consideration in analyzing the effectiveness of a mitigating control for data transfers is how much of it is automated and how much is manual. Those that are fully automated are not susceptible to human failure and, once tested, will perform the same way repeatedly.
For instance, the application or technology that is doing the transfer may be able to do an automated reconciliation of target data to source data. If the medium is custom middleware, this is particularly an achievable goal. Such an automated control could use a batch-control approach. The middleware could read the number of records, total an amount column, total another numeric column, make the transfer, and then check those batch control totals—number of records, total dollars and total number—against the target data. If all three agree, it is highly probable that the source data are the target data.
Automated reconciliations are also possible. For example, if accounting data are transferred from accounting software to a financial reporting system, which could be as simple as an electronic spreadsheet, the middleware transfer system could access the beginning balance, sum the net effect of the class of transactions for that account balance, calculate an ending balance and verify it is the ending balance in the general ledger.
A standard commercial tool that might assist in these kinds of transfers is extract, transform and load (ETL), used in posting data to a data warehouse. ETL processes are designed to detect data anomalies and errors and, thus, can be helpful in making sure data from the source database is the data in the target database and identifying errors that exist in the source data that need to be corrected. This includes missing data, as well.
In conclusion, IT auditors should look for opportunities to automate a reconciliation of source data to target data any time a data transfer occurs.
4/16/2012
 Kerry A. Anderson, CISA, CISM, CRISC, CGEIT, CISSP, ISSMP, ISSAP, CSSLP, CFE
As an information security professional, I get asked why there are so many breaches of sensitive information, with more than half a billion records breached in the last few years. My experience in the management of electronic information makes me suspect that one major reason for the frequency of breaches is the amount of sensitive information available.
Organizations collect vast stores of sensitive information, especially personal information. Once inside the IT infrastructure, they may not have a disposal mechanism to ensure that these data do not remain beyond their usefulness or official retention date.
New technologies—such as cloud-based services and mobile devices—move sensitive information outside the traditional security perimeters and associated controls. This increases the risks of over-retention and data leakage.
While compliance with regulations has been successful at creating programs to require protection for specific types of sensitive data—especially personal information—there remain large chunks of sensitive information at risk to security breaches, because it does not fit within a defined compliance category. Many breaches present the common scenario of an enterprise that achieved compliance with regulatory requirements and then suffered a later data security breach.
One possible starting place to address data breaches could be the strengthening of the synergistic affiliation between the information security and records information management (RIM) functions of the organization to address information assurance under a common umbrella. One significant delivery would be the identification of data stores throughout the organization and under management with external parties. This effort would include the flagging of all data stores containing personal information and their associated risk levels. The outcome of this effort would provide the organization with a global view of its data and the risks associated with its management. This would allow the development of common controls to diminish the potential for unauthorized release of sensitive information. This approach could offer better overall protection of sensitive data with the potential for reduction in the cost of managing specific compliance with regulatory requirements. One key risk-reduction strategy may involve the disposal of sensitive/personal information with an expired retention date and no other legal obligations for continued preservation.
Read Kerry Anderson’s recent Journal article:
“A Case for a Partnership Between Information Security and Records Information Management,” ISACA Journal, volume 2, 2012
4/9/2012
Steve Markey
In light of the data breach involving Zappos in January 2012 and Matthew J. Schwartz’s article in InformationWeek, I decided to use this space to highlight the similarities and differences between a data breach notification plan and an incident response plan.
Both types of plans require stakeholder ownership, a working document, resource allocation and a willingness to practice what the organization preaches through testing. However, an incident response plan deals with a known-unknown, while a data breach notification deals with a known-known. The latter means that an organization responding to an incident is dealing with a perceived problem, and once the incident is determined to be an actual problem then the organization will have to execute on its data breach notification plan.
Incident response and data breach notification plans differ in that data breach notification planning deals with the law vs. standards and/or best practice, as is the case with incident response planning. Furthermore, the scope of a breach notification action can quickly spiral out of control when multiple jurisdictions are affected. Beyond the law, breach notification is externally focused, which requires a well-crafted message for the customers, partners, vendors, media, public and/or government.
A breakdown of the nuances of each type of plan follows.
An incident response plan:
- Is a response to a perceived incident
- Is predominantly internally focused (e.g., employees, contractors, partners, vendors)
- Should be a requirement that is driven by industry standards, internal best practices and/or operating procedures
- May encompass multiple nuances pending the affected business ecosystem
- Requires determined process and communication flows
- Requires testing
A data breach notification plan:
- Is a response to an incident
- Is externally focused (e.g., customers, partners, vendors, media, public, government)
- Is a requirement that is driven by data protection and privacy rules and regulations
- Is costly (e.g., monetarily, customer approval/trust, brand, partner relationships)
- May encompass multiple nuances pending the affected jurisdictions/geographies
- Requires a well-crafted message
- Requires testing
Read Steve Markey’s recent Journal article:
“Testing Your Computer Security Incident Response Plan,” ISACA Journal, JOnline, volume 2, 2012 4/2/2012
Jonathan Tudor, CCNA
 My two coauthors and I started to write the Customer Relationship Information Technology Internal Control and Security (Critics) Framework a little over a year ago as part of an IT audit, control and governance course we were taking at Miami University. Originally, we found the idea of applying an IT risk mitigation framework to customer relationship management (CRM) systems a good choice for a class paper because of our academic backgrounds, which span management information systems, marketing and accounting. Now, reflecting on the data breach events of 2011, I see that IT risk mitigation for CRM systems is not only something that we had the proper background to write about, it is something that needs to be addressed with action. Action, I hope, the CRITICS Framework can help create.
2011 was arguably the most active year in history with customer-data breaches. Six months of 2011 saw more data breaches recorded than the most active month in 2010. Two of these months—June and November—set records as the most data breaches in one month—118 in June and 119 in November. Additionally in 2011, four of the largest data breaches in history occurred and two of the most expensive at Sony and Epsilon.
This information is alarming for all stakeholders involved. Customers are concerned about the security of their personal data as they hear of more data breaches and identity theft, and they begin to lose trust in companies. Executives become increasingly fearful of data breaches, as they see the huge costs, negative publicity and loss of customer trust involved. IT professionals keep working but cannot seem to keep these attacks from being successful due to either limited funding, lack of security professionals or stretched resources.
This is driving an increased attention to IT governance, control and security for customer data. CRM systems are central to this, as they are the primary systems for handling customer data. Mitigation of the business, regulatory-compliance and IT-specific risk of CRM systems will help protect companies from the harsh effects of a major data breach. A coordinated actionable approach by executive management, business, IT and security professionals is essential for success. Properly integrated governance, internal controls and security, as proposed by the CRITICS Framework, can be part of the answer to success. The stage has been set, and the negative consequences observed, now it is time for us to take action and protect customer data.
Read Jonathan Tudor, Robbie Sauerberg and Weston Smith’s recent Journal article:
“Customer Relationship Information Technology Internal Control and Security (CRITICS) Framework,” ISACA Journal, JOnline, volume 2, 2012 3/26/2012
Vasant Raval, CISA, DBA
 In this blog, I will extend my analysis of the topic of my column “Changing Times and Eternality of Ethics” in order to prompt a dialogue on ethics with IT professionals.
The precepts of ethics have been in place for as long as mankind has existed. However, it is unclear to me how our profession applies these precepts in its progressively more critical role of information governance. One gauge of our debate on ethics is the printed word. I counted the number of published manuscripts related to ethics in the ISACA Journal over the last ten years and came up with just two! Even considering that my search could be imperfect this level of exposure to what I believe to be the core of a profession is undoubtedly discouraging. Does the topic not bear upon us? Is there anything else left to absorb? Is this so-called gray area an uncomfortable place for professions that deal with black-and-white technology solutions? Or, are we getting our information on this from other sources?
Even in professions where little has changed over the years, the challenge of recognizing and addressing ethical issues remains. Here is an example unrelated to IT: the infamous Comayagua, Honduras, prison fire. On the night of the fire, only six guards were watching 800-plus prisoners in 10 blocks. There was only one set of keys, all in the hands of a lone guard who dropped the keys and fled from the scene. The result: 355 dead and counting. Should prison security authorities have thought of a disaster recovery plan? Did they have a code of ethics? Did their administration emphasize in its core values dignity of human life and duty to protect the inmates from risks of fire?
While stable environments could present ethical blunders, the gravity and variety of ethical dilemmas increases in a constantly changing landscape, as in our profession. I believe that while any change, by itself, must not be accepted as an excuse for not doing the right thing. The question is: Does the rapid change catch the IT professional off guard? Does the constant change create any blind spots? While leveraging change to create value, do we run into an ethical awareness vacuum?
Read Vasant Raval’s recent Journal column:
“Changing Times and the Eternality of Ethics,” ISACA Journal, volume 2, 2012
3/22/2012
Jonathan Trull, CISA, CFE, OSCP
 Heartbreak Ridge by Clint Eastwood is one of my all-time favorite movies. Marine gunnery sergeant, Tom “Gunny” Highway, played by Clint Eastwood is wrapping up his career after seeing extensive combat in Korea and Vietnam. In classic Eastwood style, Gunny is tough, hard-living and crude, but knows how to train and lead men into combat. In the final tour of his career, Gunny is assigned to a reconnaissance platoon filled with untested and unfit Marines with a bad attitude. Throughout the rest of the movie, Gunny sets out to prepare his men for the real fight that is sure to come.
Midway into the movie, Major Malcolm A. Powers—the incompetent senior officer overseeing Gunny’s platoon—plans and leads a training exercise in which Gunny’s platoon is to act as the enemy or red team. Major Powers leads the blue team responsible for finding Gunny’s platoon and ambushing them. Instead of allowing Gunny’s platoon to freely maneuver and attack like a real adversary, Major Powers orders Gunny to take his men to a predetermined position where they will wait to be ambushed. However, Gunny disobeys orders and leads his men on a successful counterattack against Major Powers’ poorly trained and unsuspecting forces. Major Powers is not too happy!
In a heated exchange with Major Powers, Gunny lays out several pearls of wisdom for training and leading. These can apply not only to combat troops, but also to IT security professionals:
- Train like you want to fight, because you will fight like you have trained
- Make mistakes in training—it is better and less costly than in combat or during a real (cyber)attack
In my recent Journal article, I explain how my team followed Gunny’s advice when we undertook a penetration test of the State of Colorado’s networks and IT systems. Our job—as the red team—was to attack Colorado’s systems just as a real attacker would. Our goals were (1) to test the IT security staff’s ability to detect and properly respond to our illicit activities, and (2) to identify critical weaknesses in the systems so that they could be patched before a real attack occurred.
Taking Gunny’s advice, we carried out the penetration test just as our adversaries would try to exploit us—without warning, during those days and times that are most advantageous to the attacker, and against the weakest targets, which included not just the computer systems themselves, but also the people administering and using those systems. Similar to Gunny, I had a run-in with a senior government official who was upset with the realistic nature of our attacks and was not thrilled with the number of systems being compromised by my team nor with the staff resources needed to remediate the deficiencies we had identified and exploited.
If you take just one thing away from my article it should be this: Prepare your IT security staff and infrastructure for the cyberattacks that are sure to come. My article suggests that realistic penetration tests are one of the best tools available for doing just that. Train your IT security professionals like you expect them to fight, because your systems, customers and confidential data depend on it.
Read Jonathan Trull’s recent Journal column:
“Security Through Effective Penetration Testing,” ISACA Journal, volume 2, 2012
| Copy Item to All Language Codes | | Lists/SqtResources/AllItems.aspx | 0x0 | 0x0 | ContentType | 0x01009AF1BC4E56474a80B49512D1B30D6EEC | 225 | | Manage Subscriptions | /_layouts/images/ReportServer/Manage_Subscription.gif | /Journal/Blog/_layouts/ReportServer/ManageSubscriptions.aspx?list={ListId}&ID={ItemId} | 0x80 | 0x0 | FileType | rdl | 350 | | Manage Data Sources | | /Journal/Blog/_layouts/ReportServer/DataSourceList.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x20 | FileType | rdl | 351 | | Manage Parameters | | /Journal/Blog/_layouts/ReportServer/ParameterList.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x4 | FileType | rdl | 352 | | Manage Processing Options | | /Journal/Blog/_layouts/ReportServer/ReportExecution.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x4 | FileType | rdl | 353 | | View Report History | | /Journal/Blog/_layouts/ReportServer/ReportHistory.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x40 | FileType | rdl | 354 | | View Dependent Items | | /Journal/Blog/_layouts/ReportServer/DependentItems.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x4 | FileType | rsds | 350 | | Edit Data Source Definition | | /Journal/Blog/_layouts/ReportServer/SharedDataSource.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x4 | FileType | rsds | 351 | | View Dependent Items | | /Journal/Blog/_layouts/ReportServer/DependentItems.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x4 | FileType | smdl | 350 | | Manage Clickthrough Reports | | /Journal/Blog/_layouts/ReportServer/ModelClickThrough.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x4 | FileType | smdl | 352 | | Manage Model Item Security | | /Journal/Blog/_layouts/ReportServer/ModelItemSecurity.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x2000000 | FileType | smdl | 353 | | Regenerate Model | | /Journal/Blog/_layouts/ReportServer/GenerateModel.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x4 | FileType | smdl | 354 | | Manage Data Sources | | /Journal/Blog/_layouts/ReportServer/DataSourceList.aspx?list={ListId}&ID={ItemId} | 0x0 | 0x20 | FileType | smdl | 351 | | Load in Report Builder | | /Journal/Blog/_layouts/ReportServer/RSAction.aspx?RSAction=ReportBuilderModelContext&list={ListId}&ID={ItemId} | 0x0 | 0x2 | FileType | smdl | 250 | | Edit in Report Builder | /_layouts/images/ReportServer/EditReport.gif | /Journal/Blog/_layouts/ReportServer/RSAction.aspx?RSAction=ReportBuilderReportContext&list={ListId}&ID={ItemId} | 0x0 | 0x4 | FileType | rdl | 250 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Journal/Blog/_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Journal/Blog/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Journal/Blog/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Journal/Blog/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Journal/Blog/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Journal/Blog/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Journal/Blog/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Journal/Blog/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Journal/Blog/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
|
|
|