SQL Server and Common Criteria compliance

No Responses »
Dec 222009

[updated DEC 23 07:30 AM]

Common Criteria Compliance is the testing of products by independent labs/organizations/authorities, to evaluate the product for security and assurance levels. (Even across nations). Like the Microsoft might need to have its windows compliance with the UK or China’s Assurance level. as these countries/organizations might

There are certain Security and Assurance levels set aside for a products minimum security requirements. by which the product is tested for security flaws (to put is simple) and allotted assurance certificates(levels), which are then printed on the Products Notes at SALE. We normally ignore these notes and levels, but are important to gain information on product security/assurance level.

Technically: The evaluation process establishes a level of confidence that the security functionality of these IT products and the assurance measures applied to these IT products meet these requirements.

The Orange Book and the Rainbow Series were to harsh for the business world, so the Common Criteria project started as combining several evaluation criteria’s into a common base.

In 1990, the ISO (International Organization for Standardization) identified the need of a global common international standard evaluation criteria. The Common Criteria project was started in 1993 when several organizations came together to combine existing and emerging evaluation criteria (TCSEC, ITSEC, Canadian Trusted Computer Product Evaluation Criteria [CTCPEC], and the Federal Criteria). The Common Criteria was developed through a collaboration among national security standards organizations within the United States, Canada, France, Germany, the United Kingdom, and the Netherlands.

The Benefit of Globally recognized and accepted evaluation criteria is that it helps the consumer by reducing the complexity of the ratings and eliminating the need to understand the definition and meaning of different ratings within various evaluation schemes.

Under the Common Criteria model, an evaluation is carried out on a product and is assigned an Evaluation Assurance Level (EAL).
Some of the EAL Levels are as follows:

  • EAL1 Functionally tested
  • EAL2 Structurally tested
  • EAL3 Methodically tested and checked
  • EAL4 Methodically designed, tested, and reviewed
  • EAL5 Semiformally designed and tested
  • EAL6 Semiformally verified design and tested
  • EAL7 Formally verified design and tested

That’s everything for now, we need to know about the CCC (common Criteria compliance)

In SQL Server , we can enable the Common Criteria Compliance as follows:


sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'common criteria compliance enabled', 1;
GO
RECONFIGURE
GO

in return these can be useful to comply with the CCC when using the sys.dm_exec_sessions and monitoring the

  • last_successful_logon
  • last_unsuccessful_logon
  • unsuccessful_logons

    In addition to enabling the common criteria compliance enabled option, you also must download and run a script that finishes configuring SQL Server to comply with Common Criteria Evaluation Assurance Level 4+ (EAL4+). You can download this script from the Microsoft SQL Server Common Criteria Web site.

    [ From BOL ]

    Pl visits the related links to learn more about the product evaluation

    SQL Server 2005 SP1 Enterprise Edition (32 bit)

    Certified at assurance level EAL1

    SQL Server 2005 SP2 Enterprise Edition (32 bit)

    Certified at assurance level EAL4+

    Certified to comply with US NSA DBMS Protection Profile V1.1

    SQL Server 2008 Enterprise Edition (32 bit & 64 bit)

    Certified at assurance level EAL1+

  • WARNING: BOL

    Criteria Description
    Residual Information Protection (RIP) RIP requires a memory allocation to be overwritten with a known pattern of bits before memory is reallocated to a new resource. Meeting the RIP standard can contribute to improved security; however, overwriting the memory allocation can slow performance. After the common criteria compliance enabled option is enabled, the overwriting occurs
    The ability to view login statistics

    After the common criteria compliance enabled option is enabled, login auditing is enabled. Each time a user successfully logs in to SQL Server, information about the last successful login time, the last unsuccessful login time, and the number of attempts between the last successful and current login times is made available. These login statistics can be viewed by querying the sys.dm_exec_sessions dynamic management view.
    That column GRANT should not override table DENY After the common criteria compliance enabled option is enabled, a table-level DENY takes precedence over a column-level GRANT. When the option is not enabled, a column-level GRANT takes precedence over a table-level DENY.

    References: www.ISC2.org, www.commoncriteriaportal.org/, All_In_One_CISSP_Shon Harris, Official-Guide(CISSP-ISSEP.CBK, CISSP.Prep.Guide.Gold.Edition_Ronald_Krutz, BOL (SQL Server Books Online)

    • Posted by maninder at 11:39 am Tagged with: , ,

    SOX for DBA- Part 2

    1 Response »
    Dec 212009

    In continuation to my previous post here :

    I have been working with several Financial applications, during my current/Past consulting project.
    These financial application are bucketed through SQL Server 2000 and 2005.
    Making the SQL Server SOX Compliance is a Milestone in itself.
    SOX compliance wants to see: your database server is secure and so is the database residing in it, so that it cannot be tampered, by unwanted or invited guests on the Database Server.
    I will list some strategies for making a Database Server SOX Compliance and what i have done hands-on with the database server to make them SOX compliant.

    1. Check to see unnecessary services are not running (services which are not authorized – Disable).
    2. Check Local Accounts and their rights.
    3. Check the server Policies.
    4. Check permissions for all shared folders. (Remove Unwanted Shares – Specially for Everyone)
    5. Check all Group accounts. Check the Groups and associated members and Types.(Remove unwanted)
    6. Check user account properties (Account Type/Association with Group/Pass values etc).
    7. OS Patch information.

    Now let us start with the SQL Server related Auditing:

    1. 1. Check syslogins Tables for unwanted logins (Get Rid of the logins which are not required as this possesses potential risks with users who can gain access through un-authorized manners).
    2. Regularly change SA password. (30 days or near about)
    3. Strong Passwords (min 8 characters Long with a combination of Characters and Numbers with symbols)
    4. Logins and passwords should not be the same.
    5. Incase of SQL Server 2008 – Use the Built-in Auditing Features. Check Logs at regular intervals.
    6. Check you have regular backups and those backups are secured offsite.
    7. Drop all sample Databases from your prod environment.
    8. Check the Transaction Logs are included in Critical Databases as a backup plan.
    9. Try to map all logins to description and use and you will come to know the unwanted logins.
    10. Check permissions to Extended Stored Procedures.
    11. Check sysusers tables for unwanted users in the database.
    12. Check for Orphaned Users in the Databases.(Delete the users not required or correct the mappings) I have a script which can help you do this here:
    13. Logins created since last Audit Or current Year.
    14. SQL Server Version and Service Pack Information.
    15. Check Authentication Modes (Windows or SQL or Mixed) – Auditors will ask Questions if Mixed mode.
    16. Check Guest User Access to all databases (Guest user should be disabled in all Databases).
    17. Check xp_cmdshell Status and Explain its usage.
    18. Check Linked Servers and their usage.
    19. Track Unwanted Server Activity: Monitor Error Logs and have them signed off by your Security Manager on a  weekly basis.
    20. Explain Allow Remote connection to this Server usage.

    image

    There is a UTILITY Called DUMPSEC which can be downloaded here: http://www.systemtools.com/download/dumpacl.zip
    All the information Gathering at the OS Level can be Done using DUMPSEC Utility, which was originally DUMPACL

    Also Microsoft Baseline Security Analyzer is a great place to Start, which will give you more information about windows as well as SQL Server level security conditions and suggestions.

    The SQL Server Related information can be done using Custom Scripts, which i will list down for everyone to use.
    1. Check syslogins Tables for unwanted logins
    select * from sys.syslogins where sysadmin=1 (All logins who are SA on SQL Server. Get Ready to Explain Who Who and Why they need access.)

    2. Check Permissions to Extended SP’s

    Select sysobjects.name,sysobjects.id,user_name(syspermissions.grantee) as [Granted to]
    from master..sysobjects
    Join
    master..syspermissions
    on sysobjects.id=syspermissions.id
    Where sysobjects.type=’X’
    order by name

    These were some of the scenarios, which deals with core Financial Database Auditing,as well as which should be used to secure your production Database Servers.

    Posted by maninder at 7:30 am Tagged with: ,

    SOX for DBA – Part 1

    2 Responses »
    Dec 142009

    The below information has been tapped from here: http://www.planetmagpie.com/itconsulting/complianceconsulting/sarbanesoxleycompliance.aspx Or you can read below.

    I Recommend every DBA should download/read this info: http://www.integrigy.com/security-resources/whitepapers/DBA-Guide-to-Understanding-Sarbanes-Oxley.pdf or http://www.mssqltips.com/tip.asp?tip=1300

    The Sarbanes-Oxley Act features numerous sections;

    However, three of them—302, 404 and 409—offer the greatest potential impact on companies and how the companies conduct business.

    Section 404 requires an Internal Control Report to be included in all annual financial reports. Created by a company’s auditor, the document must present management’s assertions about the design and operational effectiveness of internal controls at year end. Management must also evaluate the effectiveness of internal controls over financial reporting and disclosure controls on a quarterly basis.

    With Section 302, the CEO and CFO of a company are responsible for the accuracy, documentation and submission of financial reports and internal control structure to the SEC. Certifications signed by those two principal officers must be included in the annual or quarterly reports.

    Information must be accumulated and summarized for timely assessment and disclosure in accordance to the SEC’s rules and regulations. When Section 404 compliance is required in about a year, companies must be able to disclose on a near real-time basis—up to 48 hours—any changes in their financial condition or operations.

    Section 404 and IT.

    In general, Section 404 is the tallest mountain to climb, with key areas regarding IT controls:

    Change Management

    Companies must provide visibility over changes in the IT environment and enable the ability to initiate, authorize, manage and implement all IT changes through a systematic change process.

    Backup

    A process must be deployed to identify critical data and to duplicate, store and recover data as needed.

    Security

    A process must be deployed to ensure the integrity of information and secure applications, databases, operating systems, internal network access and perimeter network.

    Documentation

    Companies must deliver thorough documentation to cover change management, back up and security policies and processes.

    Remediation

    Companies must have solutions to fill gaps in change management, backup and security.

    SOX for DBA – Part 2

    Posted by maninder at 3:01 pm Tagged with: ,
    © 2010 D B A N A T I O N Suffusion WordPress theme by Sayontan Sinha
    Better Tag Cloud