Security architecture

1

Security Architecture

2

Security Architecture

• Application security– Planning– Development– Testing– Deployment– Maintenance

• Trusted DBMS architecture• Woods Hole architecture• Distributed architecture

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


• 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


• 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


• 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

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

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

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

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

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

Deployment

• Backups

• Documentation of installation procedure

• Responsibilities for administrators

• Verification of system when in use

• Problem resolution

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

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


• 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


• Different types of architectures available are:– Trusted Subject Architecture– Woods Hole Architectures

• Integrity lock architecture• Kernelized architecture• Replicated architecture

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


• 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


Untrusted front end Untrusted front end

Trusted DBMS

Trusted OS

DBMS

Low userHigh user

20

Woods Hole Architectures

• Developed in 1982 by the National Research Council

• Architectures are:– Integrity Lock Architecture– Kernelized Architecture– Replicated Architecture

21

Woods Hole Architectures

Untrusted front end Untrusted front end

Trusted front end

Untrusted DBMS

DBMS

Low userHigh user

22

Integrity Lock Architecture

• Users connect via untrusted front ends (UFE)

• Users perform pre- and post-processing of queries

• Trusted front end (TFE) is in between UFE and the DBMS

• Each object carries a special field called stamp containing security label and control data

23

Integrity Lock Architecture

• Integrity Lock refers to the stamp information

• TFE performs creation and validation of stamps

• Stamp usage is similar to that of checksum validation (namely TFE recalculates checksum at retrieval time and checks it against the stored checksum)

Education

Security architecture