A Resource Perspective on Cloud Sof

A Resource Perspective on Cloud Software Security
Requirements
Approaching software security requirements derivation from a resource perspective provides an effective method for addressing cloud software security
requirements. In their April 1995 paper “SMART Requirements” (www.win
.tue.nl/~wstomv/edu/2ip30/references/smart-requirements.pdf), Mike
Mannion and Barry Keepence of Napier University, Edinburgh, U.K., take this
approach by defining the following SMART basic properties that requirements
should possess:
Specific— The requirement should be unambiguous and direct. Mannion
and Keepence defi ne this characteristic as being clear, consistent, and simple.
Measurable— The requirement should be measurable to ensure that it
has been met.
Attainable— The system must be able to exhibit the requirement under
the specified conditions.
Realizable— The requirement must be achievable under the system and
project development constraints.
Traceable— The requirement should be traceable both forward and backward throughout the development life cycle from conception through
design, implementation, and test.
Source: Information Assurance Technology Analysis Center (IATC), Data and Analysis Center for Software
(DACS), “State-of-the-Art Report,” July 31, 2007.
76 Chapter 3 Cloud Computing Software Security Fundamentals
The Open Web Application Security Project (OWASP) has modified the
SMART acronym (www.owasp.org/index.php/Document_security-relevant_
requirements) to be SMART+ requirements. These requirements, taken from
the OWASP website, are as follows:
Specific— Requirements should be as detailed as necessary so there are
no ambiguities.
Measurable— It should be possible to determine whether the requirement has been met, through analysis, testing, or both.
Appropriate— Requirements should be validated, thereby ensuring both
that they derive from a real need or demand and that different requirements would not be more appropriate.
Reasonable— While the mechanism or mechanisms for implementing a
requirement need not be solidifi ed, one should conduct some validation to
determine whether meeting the requirement is physically possible, and
possible given other likely project constraints.
Traceable— Requirements should also be isolated to make them easy to
track/validate throughout the development life cycle.
Goal-Oriented Software Security Requirements
Another complementary method for performing cloud software security
requirements engineering is a goal-orientedparadigm in which a goal is a
software objective. The types of goals that are targeted are functional goals,
nonfunctional goals, security robustness, and code correctness. As Axel van
Lamsweerde, Simon Brohez, Renaud De Landtsheer, and David Janssens write in
“From System Goals to Intruder Anti-Goals: Attack Generation and Resolution
for Security Requirements Engineering,” “A goal is a prescriptive statement
of intent about some system (existing or to-be) whose satisfaction in general
requires the cooperation of some of the agents forming that system. Agents
are active components such as humans, devices, legacy software or softwareto-be components that play some role towards goal satisfaction. Goals may
refer to services to be provided (functional goals) or to quality of service
(nonfunctional goals).”
8
One implementation of goal-oriented requirements engineering is the
nonfunctional requirements (NFR) framework,
9
which provides a basis for determining if a goal has been satisfied through meeting lower-level goals.
Nonfunctional requirements include characteristics of a software system such
as reliability, performance, security, accuracy, costs, reliability, and maintainability. According to Goertzel and Winograd et al., these requirements should
specify the following:
10
Chapter 3 Cloud Computing Software Security Fundamentals 77
Properties the software must exhibit (e.g., its behavior must be correct
and predictable; it must remain resilient in the face of attacks)
Required level of assurance or risk-avoidance of individual security functions and constraints
Controls and rules governing the processes by which the software will be
built, deployed, and operated (e.g., it must be designed to operate within a
virtual machine, and its source code must not contain certain function calls)
Goertzel and Winograd et al. also provide an example of a negative nonfunctional requirement as follows: “The software must validate all input to ensure
it does not exceed the size specifi ed for that type of input.”
A related goal-oriented requirements engineering approach is the MILOS11
project methodology for goal-oriented security requirements engineering.
The MILOS security model uses generic specification patterns that map to the
information system’s properties of confi dentiality, integrity, availability, privacy,
authentication, authorization, and nonrepudiation. The security patterns are
transformed into goals that are used to develop a correlated “anti-model” that
comprises a pattern of “anti-goals” an attacker would use to prevent meeting
the specified system security goals.
NOTE Cloud software security requirements address necessary attributes
for software behavior and limitations on software functionality, whereas
cloud software requirements are concerned with necessary software functionality and performance specifications.
Monitoring Internal and External Requirements
The requirements of the information system security policy relative to software
assurance should be analyzed to ensure their consistency and correctness. Two
types of secure software requirements analysis should be performed:
Internal— Necessary in order to ascertain that the requirements are complete, correct, and consistent with the related specification requirements.
The analysis should address the following:
Security constraints
The software’s nonfunctional properties
The software’s positive functional requirements
External— Necessary to determine the following:
The software assurance requirements address the legal regulatory and
required policy issues.
78 Chapter 3 Cloud Computing Software Security Fundamentals
The nonfunctional security requirements represent a proper decomposition of the system security goals.
Software assurance requirements don’t confl ict with system security goals.
The software is resilient.
Also, in the context of internal and external access to information systems,
the issues in Table 3-1 should be considered.
Table 3-1:Internal and External Security Requirements
INTERNAL EXTERNA

Kết quả (Việt) 2:

Một nhận thức Resource Cloud Security Software
Yêu cầu
Tiếp cận các yêu cầu bảo mật phần mềm nguồn gốc từ một góc độ nguồn cung cấp một phương pháp hiệu quả để giải quyết các phần mềm bảo mật điện toán đám mây
yêu cầu. Trong tháng 4 năm 1995 giấy "Yêu cầu SMART" của họ (www.win
.tue.nl / ~ wstomv / edu / 2ip30 / tài liệu tham khảo / smart-requirements.pdf), Mike
Mannion và Barry Keepence của Đại học Napier, Edinburgh, Vương quốc Anh, cầm cái này
phương pháp tiếp cận bằng cách xác định các tính chất cơ bản SMART sau đó yêu cầu
phải có:
Specific- Yêu cầu phải rõ ràng và trực tiếp. Mannion
và Keepence Defi ne này đặc trưng như là rõ ràng, nhất quán, và đơn giản.
Measurable- Các yêu cầu nên được đo lường được để đảm bảo rằng nó
đã được đáp ứng.
Attainable- hệ thống phải có khả năng để triển lãm những yêu cầu theo
các điều kiện quy định.
 Realizable- Các yêu cầu phải đạt được theo hệ thống và
hạn chế phát triển dự án.
Traceable- Các yêu cầu nên được theo dõi cả hai phía trước và lạc hậu trong suốt vòng đời phát triển từ quan niệm thông qua
thiết kế, thực hiện và kiểm tra.
Nguồn: Đảm bảo thông tin Trung tâm Phân tích Công nghệ ( IATC), dữ liệu và Trung tâm Phân tích cho phần mềm
(DACS), "Nhà nước-of-the-nghệ thuật Report," 31 tháng 7 2007.
76 Chương 3 Phần mềm Cloud Computing an Fundamentals
The Open Web Application Security Project (OWASP) đã sửa đổi
từ viết tắt SMART (www.owasp.org/index.php/Document_security-relevant_
yêu cầu) là SMART yêu cầu +. Những yêu cầu này, lấy từ
các trang web OWASP, như sau:
Yêu cầu Specific- nên càng chi tiết càng cần thiết để có được
. không có sự mơ hồ
Measurable- Nó nên có thể để xác định xem các yêu cầu đã được đáp ứng, thông qua phân tích, thử nghiệm, hoặc cả hai.
Yêu cầu Appropriate- cần được xác nhận, qua đó đảm bảo cả hai
mà họ lấy được từ một nhu cầu thực sự hoặc nhu cầu và yêu cầu khác nhau sẽ không thể thích hợp hơn.
Reasonable- Trong khi cơ chế hoặc các cơ chế để thực hiện một
yêu cầu không cần phải là ed solidifi , ta nên tiến hành một số xác nhận để
xác định xem liệu đáp ứng yêu cầu về thể chất có thể, và
có thể đưa ra hạn chế dự án có khả năng khác.
Yêu cầu Traceable- cũng cần được cô lập để làm cho họ dễ dàng để
theo dõi / xác nhận trong suốt vòng đời phát triển.
Phần mềm Goal-Oriented Yêu cầu bảo mật
Một phương pháp bổ sung để thực hiện các đám mây bảo mật phần mềm
yêu cầu kỹ thuật là một mục tiêu orientedparadigm trong đó mục tiêu là một
mục tiêu phần mềm. Các loại mục tiêu được nhắm mục tiêu là các mục tiêu chức năng,
mục tiêu không có chức năng, sức mạnh bảo mật và mã đúng đắn. Như Axel van
Lamsweerde, Simon Brohez, Renaud De Landtsheer, và David Janssens viết trong
"từ hệ thống mục tiêu để Intruder Anti-Mục tiêu: Tấn công Generation và Nghị quyết
cho Security Requirements Engineering, "" Mục tiêu là một tuyên bố quy tắc
về ý định về một số hệ thống ( hiện tại hoặc để-được) có hài lòng nói chung
đòi hỏi sự hợp tác của một số các đại lý hình thành hệ thống đó. Đại lý
là thành phần hoạt động như con người, thiết bị, phần mềm di sản hoặc softwareto-là thành phần đóng một vai trò đối với sự hài lòng của mục tiêu. Mục tiêu có thể
tham khảo các dịch vụ được cung cấp (mục tiêu chức năng) hoặc đến chất lượng dịch vụ
(mục tiêu không có chức năng). "
8
Một thực hiện các yêu cầu về mục tiêu định hướng kỹ thuật là
yêu cầu phi chức năng (NFR) framework,
9
cung cấp một cơ sở cho việc xác định nếu một Mục tiêu đã được thỏa mãn thông qua đáp ứng mục tiêu cấp dưới.
yêu cầu không có chức năng bao gồm các đặc điểm của một hệ thống phần mềm như vậy
như độ tin cậy, hiệu suất, bảo mật, chính xác, chi phí, độ tin cậy và khả năng bảo trì. . Theo Goertzel và Winograd et al, các yêu cầu này nên
xác định như sau:
10
Chương 3 Cloud Computing Phần mềm bảo mật cơ bản 77
Properties phần mềm phải thể hiện (ví dụ, hành vi của nó phải được chính xác
và có thể dự đoán, nó vẫn phải kiên cường đứng vững các cuộc tấn công)
mức Required đảm bảo hoặc rủi ro tránh các chức năng an ninh cá nhân và hạn chế
Controls và quy định quản lý các quá trình mà các phần mềm sẽ được
xây dựng, triển khai và vận hành (ví dụ, nó phải được thiết kế để hoạt động trong một
máy ảo , và mã nguồn của nó không phải chứa các cuộc gọi chức năng nhất định)
Goertzel và Winograd et al. cũng cung cấp một ví dụ về một yêu cầu không có chức năng tiêu cực như sau: "Phần mềm này phải xác nhận tất cả các đầu vào để đảm bảo
. nó không vượt quá kích thước ed specifi cho loại đầu vào "
A yêu cầu định hướng mục tiêu tiếp cận kỹ thuật liên quan là các MILOS11
phương pháp dự án Mục tiêu định hướng yêu cầu an ninh kỹ thuật.
Các mô hình bảo mật Milos sử dụng mô hình đặc tả chung chung mà bản đồ để các
thuộc tính hệ thống thông tin của dentiality confi, tính toàn vẹn, tính sẵn có, bảo mật,
xác thực, cấp phép và chống chối bỏ. Các mô hình bảo mật được
chuyển đổi thành các mục tiêu được sử dụng để xây dựng một tương quan "anti-mô hình" mà
bao gồm một mô hình của "anti-mục tiêu" một kẻ tấn công sẽ sử dụng để ngăn chặn đáp ứng
các mục tiêu an ninh hệ thống quy định.
LƯU Ý Mây yêu cầu bảo mật phần mềm giải quyết các thuộc tính cần thiết
cho hành vi phần mềm và những hạn chế về chức năng phần mềm, trong khi
yêu cầu phần mềm điện toán đám mây có liên quan với chức năng phần mềm và thực hiện thông số kỹ thuật cần thiết.
Giám sát nội bộ và ngoài Yêu cầu
Các yêu cầu của hệ thống thông tin chính sách bảo mật liên quan đến phần mềm
đảm bảo nên được phân tích để đảm bảo tính nhất quán và đúng đắn. Hai
loại phân tích yêu cầu phần mềm an toàn phải được thực hiện:
Internal- cần thiết để xác định các yêu cầu được hoàn chỉnh, chính xác và phù hợp với các yêu cầu đặc điểm kỹ thuật có liên quan.
Các phân tích nên giải quyết như sau:
hạn chế Security
tính không có chức năng của phần mềm The
yêu cầu chức năng của phần mềm tích cực The
External- cần thiết để xác định như sau:
The yêu cầu bảo hiểm phần mềm giải quyết các quy phạm pháp luật
các vấn đề chính sách cần thiết.
78 Chương 3 Phần mềm Cloud Computing an Fundamentals
The yêu cầu bảo mật không có chức năng đại diện cho một phân hủy thích hợp của hệ thống mục tiêu an ninh.
yêu cầu đảm bảo Software làm ict không confl với mục tiêu an ninh hệ thống.
The phần mềm là khá tốt.
Ngoài ra, trong bối cảnh truy cập nội bộ và bên ngoài hệ thống thông tin,
các vấn đề trong Bảng 3-1 nên được xem xét.
Bảng 3 -1: Yêu cầu nội bộ và ngoài an
NỘI externa