P
|
roblem Definition
For the data-at-rest
security domain, one must consider the specific threat models that will be
encountered, and then choose the best methodology to protect against those
threats. For the data-at-rest case, there are several kinds of potential
threats, which primarily deal with the drives leaving the users control.
The proposed approach for protecting data is to use disk-driver based sector level
encryption method for windows based systems which results in self-encrypting partitions
of hard drive that automatically encrypt everything written to them. This is a
better solution than using a traditional hard drive and encrypting data
upstream from the drive. In this case, when the drive leaves the environment,
the attacker can read cipher text at will, and use it as a hint to crack the
data encryption keys. Encrypted partitions of drives prevent this method of
attack, by not allowing any access to data until the drive is authenticated.
I
|
ntroduction
Development of the driver for encryption ,the read and
write requests passing between the file system driver and the disk driver can
be intercepted by inserting another driver written for the purpose of
encryption, in between these two drivers.
An authentication key from an outside source is required
to unlock the drive for read/write operations. This authentication key will
typically come from a CD-ROM which has to be provided before system boot up.
After authentication is completed during power-up, encryption is transparent to
the storage system, which can then perform its usual functions in a normal
fashion.
Once authenticated, self encrypting drives appear exactly
the same as non-encrypting drives to the storage infrastructure. No changes are
required to the applications. This is in contrast with encrypting data upstream,
which can impact storage system value add operations downstream such as data
de-duplication, or compression.
When a write is performed on an encrypted partition, clear
text enters the drive and, before being written to the disk, data is encrypted and
written to it. When a read is performed, the encrypted data is decrypted before
leaving the partition.
S
|
cope and constraints (Project &
Design)
Objectives:
Ø Development of the driver for encryption ,the read and
write requests passing between the file system driver and the disk driver can
be intercepted by inserting another driver written for the purpose of
encryption, in between these two drivers.
Ø An authentication key from an outside source is required
to unlock the drive for read/write operations. This authentication key will
typically come from a CD-ROM which has to be provided before system boot up .
After authentication is completed during power-up, encryption is transparent to
the storage system, which can then perform its usual functions in a normal
fashion.
Ø Once authenticated, self encrypting drives appear exactly
the same as non-encrypting drives to the storage infrastructure. No changes are
required to the applications. This is in contrast with encrypting data
upstream, which can impact storage system value add operations downstream such
as data de-duplication, or compression.
Ø When a write is performed on a encrypted partition, clear
text enters the drive and, before being written to the disk, data is encrypted
and written to it. When a read is performed, the encrypted data is decrypted
before leaving the partition.
Scope
Ø
Addresses the issue of security of
data at rest in the hard disk.
Ø
Provides flexibility with regard to
the type of file-system being used, and the way the file system stores data on
the disk.
Ø
Provides the strong way of
authentication by implementing pre boot authentication.
Different methods for
securing data
There
have been several types of implementations for securing data in hard disks.
Ø
Starting with M. Blazes’ cryptographic
File system , In the Linux system there are the TCFS Transparent Cryptographic
File System and LoopDevices with the CryptoAPI to choose from and in the
Microsoft systems EFS Encrypting File System, is available. Although EFS is in
the kernel, it uses the services of the user-space DLLs to perform encryption
and the user-space Local Security Authentication Server for authentication.
This prevents EFS from being used for protecting files or folders in the root
or \winnt directory. The encryption keys are stored on the hard disk
using the password of the user to encrypt/secure them. Which implies that if
the password is changed accidentally, all the files encrypted with the previous
password will become useless?
Ø
Another approach is to employ StegFS
, which along with steganography uses encryption. Although StegFS achieves
plausible deniability of data's existence, the performance degradation is a
factor of 6 to 196, making it impractical for most applications.
Ø
Several approaches have been proposed
for the implementation of the encryption methods, which use different keys for
different sectors, requiring the deciphering keys/tweaks to be stored somewhere
in the encrypted partition. This however is quite difficult in the Windows
operating system. Then there is PGP, whose usage amounts to the same thing as
application level encryption.
Proposed System
Ø
A disk driver based encryption scheme
circumvents the above issues by addressing the problem at the level of raw
partitions. It also provides mandatory security, while avoiding the complexity
of the file system-based approach.
Ø
The development of the driver for
encryption is not only simple but the approach is also quite elegant and all
encompassing. This simplicity and elegance is possible because in a windows system
the drivers are layered in a form of stack, each functioning in a modular way.
Ø
To explain it briefly, the driver for the file
system takes control from the application, does the required processing, such
as parsing the filename, finding the physical location of file on the hard disk
and creating the necessary buffers.
Ø
It then passes the file to the drivers below
it in the stack. The request is parsed and processed through a chain of
drivers, till it reaches the driver at the bottom of the stack.
Ø
The read and write requests passing
between the file system driver and the disk driver can be intercepted by
inserting another driver written for the purpose of encryption, in between
these two drivers. This driver for encryption, having gotten the control of the
data passing between these two levels can do the encryption and decryption
on-the-fly.
Ø
Since the file systems access the
hard disk at the granularity of the sector, i.e. 512 bytes, each sector is read
and written independently of the other sectors.
Ø
This approach not only hides the file
system names, their sizes, directory structure, and modification dates, but
also provides flexibility with regard to the type of file-system being used,
and the way the file system stores data on the disk.
Ø
Encryption of the data is done
irrespective of the disk compression and caching schemes being used.
Ø
The enciphering transform here acts
on 512 bytes of data under the control of a secret key and a known tweak or
initialization value.
Ø
It also acts on the data of the
sector for bringing variability in the cipher text across time.
Ø
It can be implemented as a mode of
operation for any block cipher encryption scheme e.g. Advanced Encryption
Standard, AES algorithm. The ciphertext has the same length as the plain text.
System Analysis
Analysis is the process of determining the system's goals,
services and constraints by consultation
with system users. They are then defined in detail and serve as a system
specification. In other words, this is the process of deriving the system requirements
through observation of existing systems, discussions with potential users and procurers, task analysis, etc. This may involve development of one or more different system models and prototypes. These help the analyst understand the system to be specified.
specification. In other words, this is the process of deriving the system requirements
through observation of existing systems, discussions with potential users and procurers, task analysis, etc. This may involve development of one or more different system models and prototypes. These help the analyst understand the system to be specified.
Understanding the nature of the problems can be very difficult,
especially if the system is new.
Consequently, it is difficult to establish exactly what the system should do. The descriptions of the services and
constraints are the requirements for the system andprocess of finding out, analyzing, documenting and checking
these services and constraints is
called requirements engineering. The term requirement is not used throughout the software industry in a
consistent way. In some cases the requirement is seen as a high-level, abstract
statement of a service that the system should provide or a constraint on the system. At the other
extreme, it is a detailed, mathematically formal definition of a system function. The
term user requirements means the high level, abstract requirements and system requirements
means the detailed description of what the system should do. As well as these two levels
of detail, a more detailed description may be produced
to bridge the requirements engineering and design activities.
Conceptually, requirements analysis includes three types of
activity:
· Eliciting requirements: the task of communicating with
customers and users to determine what their requirements are. This is sometimes
also called requirements gathering.
· Analyzing requirements: determining whether the stated
requirements are
unclear, incomplete, ambiguous, or contradictory, and then resolving these
issues.
unclear, incomplete, ambiguous, or contradictory, and then resolving these
issues.
· Recording requirements: Requirements might be documented
in various forms, such as natural-language documents, use cases, user stories,
or process specifications.
Requirements analysis can be a long and arduous process during
which many delicate psychological skills are involved. New systems change the
environment and relationships between
people, so it is important to identify all the stakeholders, take into account
alltheir needs and ensure they understand the implications of the new systems.
Analysts can employ several techniques to elicit the requirements from the
customer. Historically, this has included
such things as holding interviews, or holding focus groups (more aptlynamed in this context as
requirements workshops) and creating requirements lists. More modern techniques include prototyping,
and use cases. Where necessary, the analyst will employ a combination of these methods
to establish the exact requirements of thestakeholders, so that a system that
meets the business needs is produced.
The software requirement specification (SRS) document generates
all necessary requirements for project development. To derive the requirements
we need to have clear and thorough understanding of the products to be
developed. This is prepared after detailed communications with project team and the customer.
F
|
unctional and Non functional
requirements
Requirements are prone to issues of ambiguity, incompleteness,
and inconsistency. Techniques
such as rigorous inspection have been shown to help deal with these issues. Ambiguities, incompleteness, and
inconsistencies that can be resolved in the requirements phase typically cost
orders of magnitude less to correct than when these same issues are found in later stages of product
development. Requirements analysis strives to address these issues.
In reality, the distinction between the different types of
requirements is not as clear cut
as these simple definitions suggest. A user requirement concerned with
security, may appear to be a
non-functional requirement. However, when developed in more detail, it may lead to other requirements that
are clearly functional such as the need to include user authorization facilities in the
system.
Functional
requirements
In software engineering, a functional requirement defines a
function of a software system or
its component. A function is described as a set of inputs, the behavior, and outputs (see also software). Functional
requirements may be calculations, technical details, data manipulation and
processing and other specific functionality that define what a system is supposed to accomplish.
Behavioral requirements describing all the cases where the system uses the functional
requirements are captured in use cases. Functional requirements are supported
by non-functional requirements (also
known as quality requirements),
which impose constraints on the design or implementation (such as performance requirements, security, or
reliability). Generally, functional requirements are expressed in the form "system
must do ",
while non-functional requirements
are "system shall be ". The plan for implementing
functional requirements is
detailed in the system design. The plan for implementing non-functional requirements is detailed in the system
architecture.
As defined in requirements engineering, functional requirements
specify particular results of a
system. This should be contrasted with non-functional requirements which specify overall characteristics such
as cost and reliability. Functional requirements drive the application architecture of a
system, while non-functional requirements drive the technical architecture of a system. In some cases a requirements analyst
generates use cases after gathering and validating
a set of functional requirements. The hierarchy of functional requirements is: user/stakeholder request - feature -. use case -. business rule. Each use case
illustrates behavioral scenarios
through one or more functional requirements. Often, though, an analyst will begin by eliciting a set
of use cases, from which the analyst can derive the functional requirements
that must be implemented to allow a user to perform each use case.
Non-functional requirements
A system has properties that emerge from the combination of its
parts. These emergent properties
will surely be a matter of accident, not design, if the non-functional requirements, or system qualities, are
not specified in advance. This white paper lays out important concepts and
discusses capturing non-functional requirements in such a way that they can drive architectural
decisions and be used to validate the architecture.
Non-functional requirements specify the system's 'quality
characteristics' or 'quality
attributes'. Potentially many different stakeholders have an interest in
getting the non-functional
requirements right. This is because for many large systems the people buying the system are completely
different from those who are going to use it (customers and users).
A good nonfunctional requirement is one that makes it clear to
everyone on the project including
the user (or someone who really understands what the user needs) — exactly how the software has to
perform. A good requirement (functional
or nonfunctional) is about
understanding and addressing the needs of a user.
Non functional
requirement in secure disk storage
Ø
Availability: should be available 24 x 7.
Ø
Reliability: the ability of a system or component to perform its
required functions under stated
conditions for a specified period of
time
Ø
Security: degree of protection against danger, damage, loss, and
criminal activity.
Ø
Robustness: ability of a computer system to cope with errors
during execution
Ø
Efficiency: resource consumption for given load.
Ø
Scalability: means to add more nodes to a system.
Ø
Response time: time a system or functional unit takes to react
to a given input.
Ø
Performance: amount of useful work accomplished compared to the time and resources used.
Domain requirements
Domain requirements are derived from the
application domain of the system rather
than from the specific needs of the system users. They must be new functional requirements in their own right;
constrain existing functional requirements or set out how particular must be carried out.
Domain requirements are important because they often reflect
fundamentals of the application domain. If these requirements are not
satisfied, it may be impossible to make the system
work satisfactorily.
In order to keep the domain manageable, it had to meet several
requirements. It had to be intuitive, meaning that the objects to be designed,
the rules the experts would follow,
and the actions needed to design the objects all had to be something most
people could envision in their
heads and not expect to need books of tables and parts lists. This was so that the system could be used
by managers, executives, and engineers with equal ease.
The domain had to lend itself to a common design paradigm. In our
case we chose the specification of a design from abstract to concrete as the
paradigm. Using this system, design
decisions would refine a structure from its most abstract form to a concrete collection
of objects with specified parameters. Other paradigms include modification of alternative designs.
The user must be able to make most of the design decisions. Design
decisions might include material selection, size of objects, placement, etc. As
many of these as possible should
be left in the hands of the user to keep the user in charge of the design. The system should help make the
choices, limiting the number of actions among which
the user has to choose. The system should handle anything which would be too repetitive or difficult for the user.
Anything that might require the user to use a calculator or book should be controlled by the
system, so that the design can remain intuitive.
User requirements
The user requirements for a system should describe the
functional and non¬ functional requirements
so that they are understandable by the system users who do not have detailed technical knowledge.
They should only specify the external behavior of the system and should avoid as far as
possible system design characteristics. Consequently, the user requirements should not be
defined using an implementation model. They must be written using natural language
forms and intuitive diagrams.
It is a good
practice to separate user requirements from more detailed system requirements in a requirements document.
Otherwise, non-technical readers of the user requirements may be overwhelmed by
details which are really only relevant for technicians.
When user requirements include too much information, it constrains
the freedom of the system
developer to provide innovative solutions to user problems and makes the
requirements difficult to understand. The user requirements should simply focus
on the key facilities to be
provided.
System requirements
A system requirements analysis takes the system design another step
closer toward technical
specification. System requirements describe, in a more technical way, the characteristics, components, and
capacities of a system that will satisfy the functional requirements. The
purpose of this system requirements analysis is to provide a sound basis for a specification of the
system architecture, an architecture that will both satisfy immediate requirements and will be
scalable and expandable to accommodate future needs.
The purpose of System Requirements Analysis is to obtain a thorough and
detailed understanding of the business need as defined.
During System Requirements Analysis, the framework for the
application is developed,
providing the foundation for all future design and development efforts.
System Requirements Analysis can be a challenging phase, because all of the major customers and their interests are brought into the process of determining requirements. The quality of the final product is highly dependent on the effectiveness of the requirements identification process. Since the requirements form the basis for all future work on the project, from design and development to testing and documentation, it the utmost importance that the project team creates a complete and accurate representation of all requirements that the system must accommodate. Accurately identified requirements result from effective communication and collaboration among all members of the Project Team, and provide the best chance of creating a system that fully raises the needs of the customers.
System Requirements Analysis can be a challenging phase, because all of the major customers and their interests are brought into the process of determining requirements. The quality of the final product is highly dependent on the effectiveness of the requirements identification process. Since the requirements form the basis for all future work on the project, from design and development to testing and documentation, it the utmost importance that the project team creates a complete and accurate representation of all requirements that the system must accommodate. Accurately identified requirements result from effective communication and collaboration among all members of the Project Team, and provide the best chance of creating a system that fully raises the needs of the customers.
T
|
ools Used (Hardware / Software)
Hardware Requirements
Hardware required to
develop the software is as listed below
Processor: Pentium IV
Processor or above
Processor Speed: 1.7
GHz or above
Hard Disk: 20 GB
Main Memory: 512 MB
RAM
Cache Memory: 1024 Kbytes
Software Requirements
Software required in
development is as listed below
Operating System:
Windows 7 32-bit version.
Others: Microsoft
visual studio 2010, windows driver kit
P
|
roject Plan (Gantt Chart)
Requirement
|
||||||||
Design
|
||||||||
Development
|
||||||||
Unit testing
|
||||||||
Testing
|
||||||||
Final Report
|
||||||||
July
|
Aug
|
Sept
|
Oct
|
Nov
|
Dec
|
Jan
|
Feb
|
lan of Analysis/Performance
Measurement
|
Two types of analysis are done.
·
How program is delivered.
·
Impact of the program.
·
Periodic
module analysis is done to check how application is shaping.
·
And
its impact on performance, cost, risk and time of delivery.
Timing depends on
- Reusable codes.
- Design of the application.
- Documentation to understand the
code.
- Knowledge of the technology and
expertise on it.
- Periodically checking
requirement is met or not.
Cost of project depends on
- Hardware cost.
- Buying license for application
and system software.
- Functionalities implemented
which are phases.
- Time of delivery.
Risk analysis and Performance is
done with below understanding.
- Analytical Data will be
collected during the SRS stage.
- Will check all the functional
and non functional requirements during the SRS stage.
- During design and development
will make sure all the requirements are met.
- Algorithms are verified in
design stage.
- In unit testing and functional
testing SRS is used for analysis.
- Ant performance tool is used
for performance checking.
- Microsoft enterprise library is used for performance improvement.
T
|
est plan and testing Methodology
The following represents the overall
flow of the testing process:
- Identify the requirements to be tested. All test
cases shall be derived using the Requirement Specification.
- Identify which particular test(s) will be used to
test each module.
- Review the test data and test cases to ensure that
the unit has been thoroughly verified and that the test data and test
cases are adequate to verify proper operation of the unit.
- Identify the expected results for each test.
- Document the test case configuration, test data,
and expected results.
- Perform the test(s).
- Document the test data, test cases, and test
configuration used during the testing process. This information shall be
submitted via the Unit/System Test Report (STR).
- Successful unit testing is required before the
unit is eligible for component integration/system testing.
- Unsuccessful testing requires a Bug Report Form to
be generated. This document shall describe the test case, the problem
encountered, it’s possible cause, and the sequence of events that led to
the problem. It shall be used as a basis for later technical analysis.
- Test documents and reports shall be submitted. Any
specifications to be reviewed, revised, or updated shall be handled
immediately.
No comments:
Post a Comment