Security Architecture

1. 1 Security Architecture

2. 2 Security Architecture Application security Planning Development Testing Deployment Maintenance Trusted DBMS architecture Woods Hole architecture Distributed architecture

3. 3 Application Security Evaluate existing architecture Existing application development teams Current network administrator practices Current security officer practices Reasonable to expect a separate SQL Server implementation for security purposes In shared systems, each application in use must use separate accounts to authenticate with the SQL Server

4. 4 Application Security Planning Existing skills base for employees is important Interoperability with existing applications Choose parameterized API for interaction with other applications for security reason Administrators and develops must be knowledgeable about application vulnerabilities E.g., In SMTP, if the body of the message contains a period followed by MAIL FROM or RCPT TO, etc, then it violates SMTP security

5. 5 Application Security Planning Develop schedule for code review involving Appropriate personnel Frequency of review Lead-time for enhancements Expected outcome Coding Input validation Credential handling encryption

6. 6 Application Security Planning Delay Development delay usually causes bypassing security features Designate an individual who can see the global picture for the project Must have sign off requirement from a security perspective before code is accepted

7. 7 Development Best practices Test thoroughly Validate input Check string lengths Audit code changes In .NET using SQLCommand object to pass parameters enhances security See example on page 211 of SQL Server security book

8. 8 Development Validate data E.g., name must contain only alphabets, spaces, hyphens and periods Delimited strings should not contain any additional delimiters When data is encoded verify that the decoded data is acceptable

9. 9 Testing Black-box testing Means testing without prior knowledge of the underlying structure or code White-box testing Means testing with prior knowledge of the underlying structure or code Hackers look for information about the system first. Black-box testing checks to see if there is information leak about the system

10. 10 Testing Common testing involves use of long strings, strings with “%n” embedded in the string Attempt source code disclosure by reinterpretation of file extension Characters such as %20, %00, %7f, %ff, %0a in URL bleed information Try traversing parent paths Test for “../../../..”

11. 11 Testing Enter overly long parameters In GET command place at least 66000 characters (usually 65536 is the limit and the rest would cause buffer overflow) Submit many meta characters Meta characters are: ‘, !, *, ., >, #, @, .., ^, &, $, ~, |, <%, <!--, --, ;, (, ), [, ], $$ Attempt SQL pass-through to a database using strings like: ‘ or true – ‘# having 1; select foo from foo--

12. 12 Deployment Backups Documentation of installation procedure Responsibilities for administrators Verification of system when in use Problem resolution

13. 13 Maintenance Development should not have access to production environment Backup and restore procedures should be tested prior to installation Routine monitoring should be in place Helpful in identifying: Bandwidth Storage Hardware Attackers Tuning database queries

14. 14 Trusted DBMS Architecture Consists of a Trusted Computing Base (TCB) that is external to the DBMS TCB could be either a trusted operating system or a trusted network TCB architecture types are: Centralized Distributed A multilevel database is stored as single level objects (files) of the operating system

15. 15 Trusted DBMS Architecture User operates at the session level established with the trusted operating system Multiple DBMSs running at different sensitivity levels may be operating at the same time Main benefit of TCB is that the trusted OS performs mandatory separation and access control

16. 16 Trusted DBMS Architecture Different types of architectures available are: Trusted Subject Architecture Woods Hole Architectures Integrity lock architecture Kernelized architecture Replicated architecture

17. 17 Trusted Subject Architecture Users with different clearance levels access the database through untrusted front-ends Untrusted front-end users are assumed to have clearances Low (U and C) and High (S and TS) High level dominates Low level Trusted DBMS is a trusted subject with respect to the OS DBMS is responsible for multilevel protection of database objects

18. 18 Trusted Subject Architecture Labels associated with DBMS subjects and objects is not comparable with Low and High levels DBMS label is assigned to both subjects and objects DBMS alone can execute code and access data with a DBMS label Subjects with a DBMS level are trusted and so they are exempt from OS mandatory controls

19. 19 Trusted Subject Architecture