2/20/2012
Angsuman Dutta and Prasad Sista
As a follow-up to our previous post, the authors would like to provide a real-life example of a global card-processing company that is on a path to improving the performance of its subledger-to-general-ledger reconciliation process while reducing operational risk via reduced error rates.
As consumers use the cards issued by the organization, millions of financial transactions are generated every day across the globe. These transactions are captured, processed and posted to a global general ledger system. While a large portion of this core process flow is automated, the balancing and reconciliation processes that manage exceptions have remained largely manual. The manual nature of these processes has led to:
- High cost of reconciliation per account
- High error rates
- Large suspense account backlog
- Inefficient process performance measurement and reporting
- High cost of audit and compliance
The organization is taking a holistic approach to addressing these challenges, enabled by a business operations management solution: Automating the balancing and reconciliation processes, where appropriate, while providing on-demand access to information for reconcilers to manage the exceptions that need manual intervention. Continuous monitoring capabilities to identify and manage process exceptions. In addition, providing extensive process measurement and reporting capabilities that enable critical analysis for process improvement while addressing the organization’s audit and compliance requirements.
Preliminary results indicate significant benefits in the following areas:
- Reduced manual effort for balancing and reconciliation
- Reduced error rates leading to overall operational risk reduction
- Reduced suspense account backlog
- Enhanced visibility into process exceptions, with a command center view
- Enhanced exception management capabilities
- Increased information availability to research exceptions that need manual intervention
- Reduced time and effort required for reporting and process measurement
- Reduced time and effort for meeting audit and compliance requirements
The organization is excited about the possibility of transforming a manual, error-prone and nonscalable process to a highly automated, responsive, accurate and scalable process that positions the organization for future growth.
2/13/2012
Seth Davis, CFA, CIA, CPCU
Members of our department have had the opportunity to present at conferences for the past few years on how we have leveraged data analytic software and our efforts regarding continuous fraud auditing. To help gauge the level of experience of the audience, we ask two questions at the start of our presentations:
- Who is using data analytic software, like ACL?
- Who is doing some form of continuous auditing?
The number of individuals and departments leveraging data analytic software has increased steadily over the years. However, the increase in those performing some form of continuous auditing has been much more subdued.
Two reasons have often been cited for the slower growth in adopting continuous auditing. One relates to how to develop fraud extracts for continuous auditing. The other is a question of whether audit will be doing management’s job for them.
In addressing the first concern, auditors need to first develop fraud extracts as part of each audit project, since the auditor is immersed in the area being audited and in the best position to identify extracts using data analytics. During the planning phase of the audit, the auditors will be documenting processes and controls, performing walk-throughs including challenging system controls, and developing a risk assessment that includes fraud-related risks. When developing an audit program to test controls, including those related to fraud risk, auditors need to develop steps that leverage data analytic tools. If this is the first time analytics are being used in an area, management needs to be made aware and support that these steps will initially take a little longer, as auditors learn how to pull in the data and put the data in a format that can be analyzed (i.e., ensure name fields in a payroll file and payment file are the same length to determine if payments have been made to employees). While initial time may be required, the benefits of identifying issues by testing 100% of the data far outweigh the start-up time and effort. More importantly, this work can be leveraged to migrate the extracts into continuous auditing.
The second concern I sometimes hear is that by doing continuous auditing, we are doing management’s job. Management is responsible for setting objectives, identifying risks, and implementing and monitoring controls. Monitoring controls typically requires some form of assessment of these controls. Internal audit may also assess controls, but this is done independent of management. If an issue is identified, a common action plan is for management to enhance their assessment efforts. With continuous auditing, we are simply accelerating the identification of concerns related to fraud and funds leakage. Neither our role nor that of management has changed. If concerns are identified as part of continuous auditing, internal auditors will meet with management to enhance their controls and monitoring efforts.
It has been great to witness the increased use of data analytics in internal audit departments over the past few years. I hope to see the use of continuous auditing accelerate as well. With the ability to leverage data analytics tools and near real-time identification of fraud and funds leakage concerns, it should not be a question of why internal audit departments are not doing continuous auditing—but why not.
Read Seth Davis, Pat Ferrell, Sean Scranton and Peter Millar’s recent Journal article:
“ The Devil’s in the Details,” ISACA Journal, volume 1, 2012 2/6/2012Tommie W. Singleton, Ph.D., CISA, CGEIT, CITP, CPA
Regular or normal access is defined in my recent Journal article as application and network access for logins and individual functionalities. How does one normally gain access to such data? There is a fair amount of focus on controls for these types of access. But, it is easy for managers and IT auditors to focus on access controls from the perspective of normal access points, and ignore other access risks.
Another risky point of access is what techies refer to as the back door. The back door would include any access from an administrative function or raw data approach.
For example, database administrators (DBAs) know enough about databases to cause havoc in them. That person also knows how to gain access to the databases. Thus, some control over DBAs and databases is an absolute must in the overall plan to secure and protect data. There have been some advances in software solutions to mitigate what DBAs can do. For instance, DBA security software is normally able to limit the DBA to access only those databases for which he/she is responsible and prevent access to other databases (if the organization is large enough to need more than one DBA).
The same is true for admin rights given to operating systems and networks. These people can access the data files and, therefore, also represent some significant risk to data security. Often the risk occurs by happenstance as IT management creates access rights for multiple IT personnel in order for them to perform certain duties. But, in allowing all IT personnel to have admin rights to the operating system or network, there is an inadvertent increase in the risk of data security, as any one of those employees has enough access to adversely affect the underlying data files.
Root kits are a tool that hackers/crackers use to gain backdoor access to data and then they carry out malicious activities as a result of that access. This type of backdoor access also needs to be considered and addressed.
The truth is, there are a number of potential backdoor access points that need to be assessed and controlled. The nature and number will vary from one organization to another, but the point is to carry out the necessary due diligence and comprehensive approach to assess and address the risks of backdoor access.
There is also the aspect of “keys to the kingdom.” This situation exists when a person has admin rights over a widespread number of servers, folders or data files as well as aspects of access controls (e.g., is also the person who assigns access control, or is able to read the access control table). Careful attention should be given to ensure proper identification of any person who has this level of access, and then, the risk associated with it should be properly mitigated.
The bottom line is that sound access control must include all major points of access risk and that appropriate controls to mitigate that risk must be implemented.
1/30/2012
Ronke Oyemade, CISA, CRISC, PMP
 For an organization to achieve its strategic goals, it needs to manage risk in an effective and timely manner. Since an organization’s resources are limited, it needs to identify risk, assess each risk in terms of the impact the occurrence of the risk will have in hindering the organization from achieving its strategic goals, and determine how much loss the enterprise is prepared to absorb and what risk it is willing to take.
A productive risk assessment by an enterprise can be achieved through effective risk awareness via communication with executive management and other stakeholders, such as the chief risk officer, enterprise risk committee, chief information officer, chief financial officer, business management and process owners, compliance and audit, human resources, external auditors, regulators, investors, insurers, IT management and other employees. To be effective, such communication should be relevant, timely, aim at the correct target audience and on a need-to-know basis. The risk information communicated should include the types of identified risk and financial indicators used in identifying risk as well as the capabilities of the enterprise (in terms of resources available to manage risk).
The enterprise can decide to manage risk through either transferring the risk to another organization such as an insurance company, avoiding the risk by eliminating the associated business process, accepting the risk based on its willingness to absorb loss, or mitigating the risks through implementing controls.
The decision on how to respond to risk should be based on a cost-benefit analysis performed within the risk-assessment process. Using this analysis, an enterprise should decide on the appropriate response, whereby the cost of responding to a risk is less than the benefit derived as a result of the response. For example, if the associated cost of mitigating a risk out ways the benefits attained from implementing a control to mitigate the risk, the enterprise should consider accepting, avoiding or transferring the risk. If the cost of implementing controls to mitigate or transfer a risk to a third party is greater than the losses incurred as a result of the risk occurring, the enterprise should consider accepting the loss. If the cost of implementing controls to mitigate or transfer a risk to a third party or accept the risk is greater than the benefits derived by the enterprise from implementing one of these mentioned risk responses or the predefined level of loss that the enterprise is prepared to absorb (with the accepted deviation from this predefined level), the enterprise should consider eliminating the business process.
Read Ronke Oyemade’s recent Journal article:
“Effective IT Governance Through the Three Lines of Defense, Risk IT and COBIT,” ISACA Journal, volume 1, 2012 1/23/2012
Rama Lingeswara Satyanarayana Tammineedi, CISA, BCCE, CBCP, CISSP, PMP
 The business continuity management (BCM) best practices and standards need to be customized to suit organizational culture and BCM requirements. When this customization is not practical and sensible, the implementation of BCM projects will be ineffective.
Based on my experience as business continuity planner, I have identified the key issues and challenges that can potentially render BCM initiatives in an organization ineffective, unless addressed appropriately.
I have summarized these issues and challenges into four major areas:
- Senior management’s commitment and involvement:
• Senior management delegating responsibility of BCM initiatives to middle management
• BCM initiatives undertaken only for compliance purposes
• Lack of collaboration between business and IT
• Too much focus on technology at the cost of other organizational resources such as people, premises, data, processes and supplies
• Lack of consensus about recovery parameters (RTO and RPO) between senior management and operations management
• Not following a single BCM framework/standard when developing business continuity and disaster recovery plans for multiple offices within an organization
- Lack of thorough understanding of the data dynamics and dependencies involved in data recovery by BCM practitioners:
• Keeping data on the end-user computing systems outside enterprise backup
• Addressing failover to an alternate site, and not focusing on the need to move operations back to a restored primary location, which can be as problematic as the failover itself
- Inappropriate approach in executing BCM processes:
• Conducting a building-wide risk assessment (rather than a service-based risk assessment) when the building accommodates multiple systems owned and managed by different functions
• Assigning equal weight to all risk attributes—severity, likelihood and nondetectability—when doing failure modes and effects analysis (FMEA)-based risk assessment
• Conducting business impact analysis (BIA) in silos by functional area, and missing the context of the wider impact of a disaster on the entire location
• Lack of knowledge of the BCM tool and its workflows at the time of developing BCM documentation
- Incorrect and/or inappropriate assumptions in formulating business continuity and disaster recovery plans:
• Failure to consider all relevant assumptions and limiting factors
I have also provided resolutions in my recent Journal article to the above key issues and challenges.
I welcome your comments and views on my article. I would appreciate your sharing of details of any other issues and challenges you might have faced in implementing BCM projects in your organization.
Read Rama Lingeswara Satyanarayana Tammineedi’s recent Journal article:
“ Key Issues, Challenges and Resolutions in Implementing Business Continuity Projects,” ISACA Journal, volume 1, 2012
1/16/2012Angsuman Dutta and Prasad Sista
With increasing pressures to cut costs and improve efficiency, accelerating need for accurate, real-time operational information for decision making, and an expanding array of regulations calling for greater visibility and transparency, leading organizations are transforming their back-office operations to align and integrate multiple objectives such as risk management, process improvement and performance measurement.
Back-office operations can be categorized into three fundamental types of processes:
- Core processes—Capturing, processing, recording, accounting and reporting transactions originated at the front office. Examples include claims processing, payments and accounting.
- Management processes—Includes balancing and reconciliation, monitoring and measurement to ensure integrity, and performance. Examples include risk management and control initiatives.
- Governance processes—Internal and external audit as well as risk assessment, to test, validate and certify the integrity of the core and management processes. Examples include internal and external audit and certifications.
Inefficiencies, risks and performance issues in these processes stem from multiple sources including information silos corresponding to product lines, mergers and acquisitions, and the prevalence of manual steps. Leading organizations primarily in the financial services sector have initiated projects to achieve operational transformation at all levels: core operations, operations management and operations governance. Some of the repeat themes across these projects are automation, standardization, centralization and innovation. These themes drove large transformational initiatives in the core processes of organizations. We are now seeing the same themes applied to the management and governance layer primarily in:
- Operational control—A system of checks, balances and reconciliations. Automation of controls reduces manual processing, thereby reducing cycle time and risks associated with the process, and greatly improving its performance.
- Operational insight—Allows for real-time information to be consistently monitored ensuring end-to-end business visibility into operations, resulting in better decisions in near real time.
- Operational improvement—Heavily reliant upon measurement. Automated measurement enables real-time reports that help operational managers to keep track of process performance and user productivity.
The emerging trends of automation, standardization, centralization and innovation of operations management processes, such as controls, monitoring and measurement, have created a path for organizations to gain efficiencies in their back-office operations while simultaneously reducing operational risk. This path is timely in the current economic environment that demands organizations to quickly adjust to the new, normal economic reality of doing more with less.
1/9/2012
Mathew Nicho, Ph.D., CEH, SAP-SA, RWSP
 The year 2011 has witnessed a spate of high-profile data breaches into well-fortified networks mainly using advanced persistent threat (APT) mode. We saw attackers targeting the weakest link in the network through a combination of social networking and technological skills.
On the other hand, network security has advanced to a stage where direct hacking is losing its appeal. Moreover, organizations do have a wide range of information systems (IS) controls (term used here to denote IS controls, frameworks, standards and regulations alike) to select from. These range from technical-oriented frameworks focusing on the more specific data protection (namely PCI DSS) to the generic but comprehensive information governance framework, COBIT—apart from commonly used standards, such as the ISO 27000 series, NIST standards and numerous country-specific regulations on information and data protection and privacy.
Does the recent spate of breaches mean that the existing IS security controls, frameworks, standards and regulations are not enough to ensure adequate protection against these attacks? Or, is it because these IS controls are scattered and not integrated into a unified IS security governance framework?
While it is impossible to ensure 100% protection against any IS attacks, efficient, effective and adequate protection can be ensured through:
- Mapping the controls of COBIT with PCI DSS (and/or relevant control frameworks) to avoid duplication (efficiency)
- Incorporating the best practices of COBIT, like the RACI chart, and information criteria (based on the extended CIA triangle), into PCI DSS (and/or relevant control frameworks), using a two-, three- or multi-dimensional measurement tool to reach a consensus of the performance of relevant controls rather than a simple tick-box approach (effectiveness)
- Selecting, customizing and prioritizing relevant controls (from relevant IS control frameworks) for the organizations for adequate protection
It seems to me that the current IS security and governance domain is likened to the pre-ERP era of the 1980s in which applications and databases were scattered, siloed and duplicated.
Do we need an integrated unified IS security governance framework that is specific enough to control and identify the weakest link, technical enough to deter sophisticated attacks, comprehensive enough to cover the whole IS domain in the enterprise, sharp enough (measurement focus) to measure any deviations of any controls from the benchmark, and dynamic enough to take care of existing and new emerging threats?
Read Mathew Nicho’s recent Journal article:
“Incorporating COBIT Best Practices in PCI DSS V2.0 for Effective Compliance,” ISACA Journal, volume 1, 2012 1/3/2012
Peter Millar
It is generally believed that fraudsters commit their acts because they do not think that they will be caught. Adding new rules or encouraging whistle-blowers will not, in my opinion, cause fraudsters to change their ways.
While whistle-blower programs, fraud hotlines and other ways for employees to alert their organizations to fraudulent activity are important and necessary elements to safeguarding an organization from fraud, they aren’t in themselves sufficient. This is borne out by the statistic that fraudulent activities last a median of 18 months before discovery!1 Surely we can do better.
So the questions to ask are: How can one detect fraud sooner, rather than later? How can an organization proactively detect fraud as opposed to waiting for some Good Samaritan to blow the whistle?
One answer is to put detective measures in place and let everyone know that they are running 24/7. This can help create an environment where the risk of getting caught outweighs the possible gain of committing fraud. By detective measures, I am referring to leveraging audit analytics technology to seek out indicators of fraud in an organization’s data. When these measures are applied either on a periodic or a continuous basis (continuous auditing or monitoring) and everyone is aware of their existence, detective measures become preventative in nature.
Applying audit analytics to fraud detection can be done in incremental phases. It doesn’t mean doing nothing one day and implementing a full suite of fraud detection tests the next day. Experience has shown that successful organizations that are leveraging audit analytics technology to the fullest are the ones that have established a good solid foundation in people, processes and technology.
Competency in understanding key business processes and being able to analyze and interpret the data that reflects those activities is a requirement. Likewise, organizations need to develop increasing levels of sophistication in using audit analytics if they are to implement a technology-enabled fraud detection and prevention program.
We all can do a better job of detecting fraud sooner rather than later. Audit departments can play a key role in making all that happen by leveraging their skills, approaches and technologies to catch fraudsters sooner—and challenge their belief that they won’t get caught.
Endnote1 Association of Certified Fraud Examiners (ACFE), “2010 Report to the Nations,” www.acfe.org/ 12/19/2011
Ed Gelbstein, Ph.D.
 I believe that data integrity has not been given the attention it deserves for years. IT professionals tend to see it as someone else’s problem. True, the IT function does not “own” the data and cannot decide on user access rights and privileges.
COBIT 4.1 touches on this (DS5 and DS11) and I’m looking to COBIT 5.0 to gives stronger guidelines and generate greater engagement from systems and data owners. But there is more to it: While organizations have learned to live with two common attacks on data integrity—web site defacements and fraud—they may not be prepared for the threat of a data integrity attack on critical information infrastructure (CII).
We now know that no organization is invulnerable. Three recent events illustrate this… Wikileaks made headlines everywhere. This was a deliberate disclosure of confidential information by a person with legitimate access to it. UBS London lost an estimated US $3 billion through unauthorized trades—an insider’s action that received some media attention. And, finally, Stuxnet, which barely made the popular news. However, these are the tip of the proverbial iceberg.
I consider Stuxnet as proof that damaging data integrity attacks are feasible and effective. The media speculated that an attack of such sophistication required resources and expertise that only governments can provide. While no country has admitted being involved in the development of Stuxnet, many are officially known to be preparing for “offensive computer warfare.”
In May 2011, General K. Chilton of the US Military Strategic Command stated that “In the event of a cyberattack, the laws of armed conflict will apply.” This assumes that military-grade malware could be used as a weapon (there are no international treaties on this subject) and, therefore, CIIs should be considered attractive targets to cause massive disruption.
Security professionals who I have met at conferences usually admit “off the record” that their CIIs are not well prepared to deal with such an attack (due to budget cuts, inability to recruit and retain experienced professionals, organizational culture, lack of executive interest, or weak corporate governance of IT).
But the problem extends beyond IT. Do you remember how Y2K brought to our attention ubiquitous embedded systems and systems control and data acquisition (SCADA)? Both are unsophisticated and unprotected technologies not managed by the IT function and, largely, invisible. Could you provide assurances to your executives that your organization is well prepared?
Read Ed Gelbstein’s recent Journal article:
“Data Integrity—Information Security’s Poor Relation,” ISACA Journal, volume 6, 2011 12/12/2011
Aditya K. Sood and Richard J. Enbody, Ph.D.
 Exploitation has migrated from systems to the web with the advent of new technologies. Hardware devices such as disk managers, firewalls, routers, modems and switches used in home and organizational networks rely on administrative interfaces that include both web consoles and back-end login consoles such as FTP and Telnet. Recent studies have revealed that these devices are not immune to security vulnerabilities. Our recent Journal article focuses on vulnerabilities in hardware devices that can be exploited through their administrative consoles. Security solutions to protect these devices against cross-interface attacks are also described.
It is well known that Cross-site Scripting (XSS) and Cross-site Request Forging (CSRF) attacks are used to spread malware and to execute remote commands, respectively. In contrast, our article examines Cross-interface Attacks (CIA)—a variant of these attacks in which an FTP login console is used as an entry point to inject payloads through username and password fields. Due to inherent weaknesses in the design of web-based log management systems, the injected payload results in command execution. Additionally, malicious JavaScripts can be injected into these devices to execute malicious content from the remote servers.
In addition, in the article, we make the observation that the exploitation risk is not confined to organizational networks, but also applies to home and small business networks relying on hardware devices. These devices are often not as well managed as system devices, so they provide ripe opportunities for attack. Therefore, it is imperative to ensure that these relatively simple hardware convenience devices should be developed with security considerations.
Read Aditya K. Sood and Richard J. Enbody’s recent Journal article:
“Persistent Cross-Interface Attacks,” ISACA Journal, volume 6, 2011 | 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 |
|
|
|
|
|