<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:syn="http://purl.org/rss/1.0/modules/syndication/"
         xmlns="http://purl.org/rss/1.0/">




    



<channel rdf:about="http://www.integrigy.com/security-resources/whitepapers/whitepapers-presentations/RSS">
  <title>Whitepapers and Presentations</title>
  <link>http://www.integrigy.com</link>
  
  <description>
    
       
       
  </description>
  
  
  
            <syn:updatePeriod>daily</syn:updatePeriod>
            <syn:updateFrequency>1</syn:updateFrequency>
            <syn:updateBase>2006-07-18T19:54:09Z</syn:updateBase>
        
  
  <image rdf:resource="http://www.integrigy.com/Integrigy_logo.gif"/>

  <items>
    <rdf:Seq>
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/IOUG_Real-life_Database_Security_Mistakes.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/IOUG_Oracle_Critical_Patch_Updates_Unwrapped.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/OAUG_Oracle_Critical_Patch_Updates_Insight_and_Understanding.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/Building_an_Audit_Trail_in_an_Oracle_Applications_Environment.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Listener_TNS_Security.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_11i_Security_Quick_Ref.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Apps_PCI_Compliance.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_SQL_Injection_Attacks.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Hashing_Credit_Card_Numbers_Unsafe_Practices.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_11i_Credit_Cards_PCI.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Apps_Password_Issue.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Evading_Oracle_IDS.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/FISMA-ORACLE-Report-Card-2005.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/DBA-Guide-to-Understanding-Sarbanes-Oxley.pdf"/>
        
        
            <rdf:li rdf:resource="http://www.integrigy.com/security-resources/whitepapers/DBA-Guide-to-Understanding-Sarbanes-Oxley-Presentation.pdf"/>
        
    </rdf:Seq>
  </items>

</channel>

    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/IOUG_Real-life_Database_Security_Mistakes.pdf">        <title>IOUG - Real-life Database Security Mistakes</title>        <link>http://www.integrigy.com/security-resources/whitepapers/IOUG_Real-life_Database_Security_Mistakes.pdf</link>        <description>IOUG COLLABORATE 08 Presentation - You did everything by the book, followed the database security checklists, and implemented security best practices, but one day you find significant security issues in one of your databases. How did this happen? After auditing hundreds of databases, I have compiled a list of common database security mistakes and potentials causes of each mistake. Learn from other's mistakes and what you can do to prevent these mistakes from happening on your watch. Common database security mistakes can impact every aspect of the Oracle Database and include reappearing default passwords, misapplied Critical Patch Update security patches, and wayward privileges and grants. Time is the chief enemy of database security as many security mistakes are innocently introduced over time, so security needs to be a process rather than a one-time task.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>skost</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>COLLABORATE</dc:subject>                    <dc:subject>Oracle Database</dc:subject>                <dc:date>2008-04-18T18:25:31Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/IOUG_Oracle_Critical_Patch_Updates_Unwrapped.pdf">        <title>IOUG - Oracle Database Critical Patch Updates Unwrapped</title>        <link>http://www.integrigy.com/security-resources/whitepapers/IOUG_Oracle_Critical_Patch_Updates_Unwrapped.pdf</link>        <description>IOUG COLLABORATE 08 Presentation - Ever wonder what is being fixed in an Oracle Critical Patch Update? As a follow-up to the 2007 IOUG SELECT Journal article "Oracle Critical Patch Updates: Common Questions", this session will provide an inside look at the Critical Patch Updates (CPU) and the security bugs fixed by the CPU patches. Understand what are buffer overflows and SQL injection attacks by seeing how these types of security bugs compromise the security of the database. Learn about the complexities of the CPU patches including certification issues, patch differences across operating systems, and why the latest database version may have not yet released security fixes. Best practices for installing and testing CPU patches will be discussed.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>skost</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>COLLABORATE</dc:subject>                    <dc:subject>Oracle Database</dc:subject>                    <dc:subject>Oracle Critical Patch Update</dc:subject>                <dc:date>2008-04-18T18:23:09Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/OAUG_Oracle_Critical_Patch_Updates_Insight_and_Understanding.pdf">        <title>OAUG - Oracle E-Business Suite Critical Patch Updates: Insight and Understanding</title>        <link>http://www.integrigy.com/security-resources/whitepapers/OAUG_Oracle_Critical_Patch_Updates_Insight_and_Understanding.pdf</link>        <description>OAUG COLLABORATE 08 Presentation - Security bugs in Oracle Applications are fixed by Oracle on a quarterly basis with Critical Patch Updates (CPU). The security researcher who has discovered many of these bugs will provide insight into the types of security issues fixed by these patches. Understand what are buffer overflows and SQL injection attacks by seeing how these types of security bugs compromise the security of Oracle Applications. Best practices for installing and testing CPU patches will be discussed.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>skost</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>COLLABORATE</dc:subject>                    <dc:subject>Oracle E-Business Suite</dc:subject>                    <dc:subject>Oracle Critical Patch Update</dc:subject>                <dc:date>2008-04-18T18:22:48Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/Building_an_Audit_Trail_in_an_Oracle_Applications_Environment.pdf">        <title>Building an Audit Trail in an Oracle Applications Environment</title>        <link>http://www.integrigy.com/security-resources/whitepapers/Building_an_Audit_Trail_in_an_Oracle_Applications_Environment.pdf</link>        <description>Sarbanes-Oxley’s section 404 requires a company’s key systems be audited. However, many companies have 'unauditable' systems and don’t even know it. This paper explores methods by which companies can create an auditable system by implementing various levels of audit trails in Oracle Applications.  This paper was co-written with Jeffrey Hare of ERP Seminars and was the featured article in the Spring 2006 issue of OAUG Insight magazine.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>ploneadmin</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>Sarbanes-Oxley (SOX)</dc:subject>                    <dc:subject>Oracle E-Business Suite</dc:subject>                <dc:date>2007-04-11T20:01:06Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Listener_TNS_Security.pdf">        <title>Oracle Database Listener Security Guide</title>        <link>http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Listener_TNS_Security.pdf</link>        <description>A guide to properly securing the Oracle Database Listener. Integrigy Consulting has found the Database Listener to be one of the most frequently overlooked security risks at customers. An overview of the Database Listener, its unique security risks, and step-by-step recommendations for securing it are provided.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>ploneadmin</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>Oracle Listener</dc:subject>                    <dc:subject>Oracle Database</dc:subject>                <dc:date>2007-04-01T00:26:08Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_11i_Security_Quick_Ref.pdf">        <title>Oracle Applications 11i Security Quick Reference</title>        <link>http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_11i_Security_Quick_Ref.pdf</link>        <description>A quick reference card with important security information for Oracle Applications 11i. This handy card lists default user accounts, default ports, important patches, and auditing setups.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>ploneadmin</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>Oracle E-Business Suite</dc:subject>                <dc:date>2007-03-27T16:18:34Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Apps_PCI_Compliance.pdf">        <title>Credit Cards and Oracle Applications: Security and PCI Compliance Issues</title>        <link>http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Apps_PCI_Compliance.pdf</link>        <description>Credit card data breaches are headline news, thus organizations must properly protect credit card data or risk being tomorrow's headline.  Oracle Applications implementations that "store, process, or transmit cardholder data" must comply with Payment Card Industry (PCI) security standards regardless of size or transaction volume.  PCI is focused on securely handling cardholder data, but also has a significant emphasis on general IT security.  The difficultly with Oracle Applications and achieving PCI compliance is that even though credit card processing may be only a one minor feature, the entire application installation must be fully PCI compliant due to the tight-integration and data model of Oracle Applications.  This presentation will review the credit card processing within Oracle Applications and will provide general guidance for Oracle Applications implementations on securing cardholder data and complying with relevant PCI requirements.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>skost</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>PCI</dc:subject>                    <dc:subject>Oracle E-Business Suite</dc:subject>                <dc:date>2007-03-13T19:13:46Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_SQL_Injection_Attacks.pdf">        <title>An Introduction to SQL Injection Attacks for Oracle Developers</title>        <link>http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_SQL_Injection_Attacks.pdf</link>        <description>Most application developers underestimate the risk of SQL injections attacks against web applications that use Oracle as the back-end database. This paper is intended for application developers, database administrators, and application auditors to highlight the risk of SQL injection attacks and demonstrate why web applications may be vulnerable.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>ploneadmin</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>Oracle</dc:subject>                    <dc:subject>SQL Injection</dc:subject>                <dc:date>2007-03-28T04:20:42Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Hashing_Credit_Card_Numbers_Unsafe_Practices.pdf">        <title>Hashing Credit Card Numbers: Unsafe Application Practices</title>        <link>http://www.integrigy.com/security-resources/whitepapers/Integrigy_Hashing_Credit_Card_Numbers_Unsafe_Practices.pdf</link>        <description>Cryptographic hash functions seem to be an ideal method for protecting and securely storing credit card numbers in ecommerce and payment applications.  A hash function generates a secure, one-way digital fingerprint that is irreversible and meets frequent business requirements for searching and matching of card numbers.  However, due to the predictability of credit card numbers and common business requirements in processing credit cards, ecommerce and payment applications may implement such hashing of card numbers in an unsafe manner that allows an attacker to obtain a large percentage of card numbers by brute forcing compromised hashes in a matter of hours.
This paper is an analysis of actual application practices for storing of credit card number hashes and a review of brute force attack methods against such hashes.   The impetus for this paper was identification of this issue during multiple application security assessments.  The objective is to highlight the weakness of common credit card hashing techniques and to educate application architects and programmers on the issues of storing credit card numbers as hashes.
</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>skost</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>PCI</dc:subject>                <dc:date>2007-03-02T03:37:55Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_11i_Credit_Cards_PCI.pdf">        <title>Oracle Applications 11i: Credit Cards and PCI Compliance Issues</title>        <link>http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_11i_Credit_Cards_PCI.pdf</link>        <description>All Oracle Applications implementations that "store, process, or transmit cardholder data" must comply with Payment Card Industry (PCI) Data Security Standard 1.1 regardless of size or transaction volume.  The PCI Data Security Standard (DSS) 1.1 is a set of stringent security requirements for networks, network devices, servers, and applications.  The difficultly with Oracle Applications and achieving PCI compliance is that even though credit card processing may be only a one minor feature of the application, the entire application installation must be fully PCI DSS compliant due to the tight-integration and data model of Oracle Applications.  This paper reviews the credit card processing features of Oracle Applications and provides general guidance for Oracle Applications implementations on complying with relevant PCI DSS requirements.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>skost</dc:creator>        <dc:rights></dc:rights>                <dc:date>2007-03-28T04:58:42Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Apps_Password_Issue.pdf">        <title>Oracle Applications Password Decryption</title>        <link>http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Apps_Password_Issue.pdf</link>        <description>Most Oracle Applications 11i implementations are vulnerable to a significant security weakness in the encryption of passwords within the application where an insider may be able to circumvent all application controls by accessing any application account or obtain the APPS database account password.  This issue is really a "perfect storm" with the convergence of (1) an inherent architectural weakness in the application, (2) generally accepted insecure operational procedures for ad-hoc query access and cloning, and (3) multiple examples of effective, easy to execute exploit code for decrypting application passwords.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>skost</dc:creator>        <dc:rights></dc:rights>                <dc:date>2007-03-02T03:28:32Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/Integrigy_Evading_Oracle_IDS.pdf">        <title>Evading Network-Based Oracle Database Intrusion Detection Systems</title>        <link>http://www.integrigy.com/security-resources/whitepapers/Integrigy_Evading_Oracle_IDS.pdf</link>        <description>With the advent of legislative mandates like Sarbanes-Oxley (SOX) and the Health Insurance Portability and Accountability Act (HIPAA), the security and auditing of Oracle Databases has become much more of a priority for most organizations.  A common solution has been to implement an Oracle-aware Intrusion Detection System (IDS) or auditing product to address these legislative mandates and increased auditor scrutiny.  This paper looks at a number of techniques that may be used to evade such Oracle intrusion detection and auditing solutions, especially signature-based solutions.
</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>skost</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>Sarbanes-Oxley (SOX)</dc:subject>                    <dc:subject>Oracle Database</dc:subject>                <dc:date>2007-03-02T03:29:59Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/FISMA-ORACLE-Report-Card-2005.pdf">        <title>FISMA and Oracle: 2005 Report Card</title>        <link>http://www.integrigy.com/security-resources/whitepapers/FISMA-ORACLE-Report-Card-2005.pdf</link>        <description>The Federal Information Security Management Act (FISMA) of 2002 requires all government agencies to submit to the Office of Management and Budget an annual evaluation of IT security across the agency.  The overall results of these reports are complied and reported in the annual "Federal Computer Security Report Card", which scored the Federal government a D+.  One aspect of the evaluation process relates to the use of configuration policies for Oracle.  We reviewed the publicly available agency reports to compile an Oracle-specific report card to see how agencies are doing with one small slice of FISMA.  The results are not encouraging -- even agencies that achieved high overall scores have not implemented configuration policies for Oracle.  The overall Oracle grade is a D-.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>skost</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>Oracle</dc:subject>                    <dc:subject>FISMA</dc:subject>                    <dc:subject>Oracle Database</dc:subject>                <dc:date>2007-03-02T03:31:20Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/DBA-Guide-to-Understanding-Sarbanes-Oxley.pdf">        <title>DBA Guide to Understanding Sarbanes-Oxley (SOX) [Whitepaper]</title>        <link>http://www.integrigy.com/security-resources/whitepapers/DBA-Guide-to-Understanding-Sarbanes-Oxley.pdf</link>        <description>The Sarbanes-Oxley Act (SOX) never mentions the words database or data, however, DBAs must ensure their databases are in compliance with Sarbanes-Oxley. Sarbanes-Oxley Section 404 simply states that management has the responsibility “for establishing and maintaining an adequate internal control structure and procedures for financial reporting.” How does this sentence relate to a database being compliant with Sarbanes-Oxley? Well, directly it doesn’t. But since the Oracle Applications 11i database contains data related to financial reporting and manipulation of this data “could adversely affect the company’s ability to record, process, summarize, and report financial data”, the Oracle Applications database must be compliant with the requirements of Sarbanes-Oxley for effective internal controls as stated in Sections 302 and 404 of the Act.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>ploneadmin</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>Sarbanes-Oxley (SOX)</dc:subject>                    <dc:subject>Oracle E-Business Suite</dc:subject>                <dc:date>2007-03-02T03:34:30Z</dc:date>        <dc:type>File</dc:type>    </item>
    <item rdf:about="http://www.integrigy.com/security-resources/whitepapers/DBA-Guide-to-Understanding-Sarbanes-Oxley-Presentation.pdf">        <title>DBA Guide to Understanding Sarbanes-Oxley (SOX) [Presentation]</title>        <link>http://www.integrigy.com/security-resources/whitepapers/DBA-Guide-to-Understanding-Sarbanes-Oxley-Presentation.pdf</link>        <description>The Sarbanes-Oxley Act (SOX) never mentions the words database or data, however, DBAs must ensure their databases are in compliance with Sarbanes-Oxley. Sarbanes-Oxley Section 404 simply states that management has the responsibility “for establishing and maintaining an adequate internal control structure and procedures for financial reporting.” How does this sentence relate to a database being compliant with Sarbanes-Oxley? Well, directly it doesn’t. But since the Oracle Applications 11i database contains data related to financial reporting and manipulation of this data “could adversely affect the company’s ability to record, process, summarize, and report financial data”, the Oracle Applications database must be compliant with the requirements of Sarbanes-Oxley for effective internal controls as stated in Sections 302 and 404 of the Act.</description>        <dc:publisher>No publisher</dc:publisher>        <dc:creator>ploneadmin</dc:creator>        <dc:rights></dc:rights>                    <dc:subject>Sarbanes-Oxley (SOX)</dc:subject>                    <dc:subject>Oracle E-Business Suite</dc:subject>                <dc:date>2007-03-02T03:33:16Z</dc:date>        <dc:type>File</dc:type>    </item>




</rdf:RDF>
