Fault InjectionFault injection is a

Fault Injection
Fault injection is a technique used to improve code coverage by testing all
code paths, especially error-handling code paths that may not be exercised
during functional testing. In fault injection testing, errors are injected into the
cloud software to simulate unintentional user errors and intentional attacks on
the software through its environment, and attacks on the environment itself.
Source Code Fault Injection
In source code fault injection, the tester decides when environment faults should
be triggered. The tester then “instruments” the source code by non-intrusively
inserting changes into the program that reflect the changed environment data
that would result from those faults.
22
The instrumented source code is then
compiled and executed, and the tester observes how the executing software’s
state changes when the instrumented portions of code are executed. This enables
the tester to observe the secure and nonsecure state changes in the software
resulting from changes in its environment.
The tester can also analyze how the cloud software’s state changes as a result
of a fault propagating through the source code. This type of analysis is typically
referred to as fault propagation analysis, and involves two techniques of source
code fault injection: extended propagation analysisand interface propagation analysis.
96 Chapter 3 Cloud Computing Software Security Fundamentals
To prepare for fault propagation analysis, the tester must generate a fault tree
from the software’s source code. To perform an extended propagation analysis,
the tester injects faults into the fault tree, then traces how each injected fault
propagates through the tree. This shows the impact a particular fault will have
on the overall behavior of the software.
Interface propagation analysis focuses on how faults are propagated through
the interfaces between the component/module and other cloud application-level
and environment-level components. In interface propagation analysis, the tester
injects a fault into the data inputs between components, views how the resulting
faults propagate, and observes whether any new anomalies result. This type
of analysis enables the tester to determine how the failure of one component
can affect the failure of a neighboring component, particularly important if a
neighboring cloud component is of high consequence.
Source code fault injection is particularly useful in detecting the following:
Incorrect use of pointers and arrays
Use of dangerous calls
Race conditions
Source code fault injection should be performed iteratively as the software
is being written. When new threats (attack types and intrusion techniques) are
discovered, the source code can be re-instrumented with faults that are representative of those new threat types.
Binary Fault Injection
Binary fault injection is a runtime analysis technique whereby an executing cloud
application is monitored as faults are injected. By monitoring system call traces,
a tester can identify the names of system calls, the parameters to each call, and
the call’s return code. This enables the tester to discover the names and types of
resources being accessed by the calling software, how the resources are being
used, and the success or failure of each access attempt. In binary fault analysis,
faults are injected into the environment resources that surround the cloud
application. Environmental faults provide the tester with a number of benefits:
They simulate real-world attack scenarios and can be easily automated.
They simulate environment anomalies without requiring an understanding
of how those anomalies actually occur in the real world. This enables fault
injection by testers who do not have prior knowledge of the environment
whose faults are being simulated.
The tester can choose when to trigger a particular environmental fault.
This avoids the problem of a full environment emulation in which the
environment state when the application interacts with it may not be what
is expected, or may not have the expected effect on the software’s behavior.
Chapter 3 Cloud Computing Software Security Fundamentals 97
It is diffi cult to predict the complex inputs the cloud software will actually
receive in its target environment. Therefore, fault injection scenarios should be
designed to give the tester the most complete understanding possible of the
security of the behaviors, states, and properties of the software system under
all possible operating conditions. Once the cloud application has been deployed
to production, the tester can employ penetration testing and vulnerability scanning to provide an additional measure of the application’s security posture.
Binary fault injection tools include binary fault injectors and brute-force
testers. These tools should support the common functionality found in
the application. For example, the commercial fault injection tool Holodeck
(www.securityinnovation.com/holodeck/) is often used to simulate faults in
Microsoft operating system applications. Holodeck injects faults for common
functionality found in a typical Windows environment such as the following:
Network— Cable disconnected, network not installed, wrong Winsock
version, Winsock task limit reached, no ports available, network is down
Disk— Insufficient disk space, cyclic redundancy check (CRC) errors, too
many fi les open, disk is write-protected, no disk is in the drive
Memory— Insufficient memory, failure to allocate, locked memory
Holodeck also supports monitoring an application to watch its interactions
with the environment.
Dynamic Code Analysis
Dynamic code analysis examines the code as it executes in a running cloud
application, with the tester tracing the external interfaces in the source code to
the corresponding interactions in the executing code, so that any vulnerabilities
or anomalies that arise in the executing interfaces are simultaneously located
in the source code, where they can then be fixed.
Unlike static analysis, dynamic analysis enables the tester to exercise the
software in ways that expose vulnerabilities introduced by interactions with
users and changes in the configuration or behavior of environment components. Because the software isn’t fully linked and deployed in its actual target
environment, these interactions and their associated inputs and environment
conditions are essentially simulated by the testing tool.
An example of a dynamic code analysis toolset is the open-source Valgrind
(www.valgrind.org), which is useful in detecting memory management and
thread bugs.
Property-Based Testing
Property-based testing is a formal analysis technique developed at the University
of California at Davis.
23
Property-based testing validates that the software’s
implemented functionality satisfies its specifications. It does this by examining
98 Chapter 3 Cloud Computing Software Security Fundamentals
security-relevant properties revealed by the source code, such as the absence of
insecure state changes. Then these security-relevant properties in the code are
compared against the software’s specification to determine whether the security
assumptions have been met.
Like direct code analysis, property-based testing requires the full concentration of the tester and is a detail-oriented process. Because it requires the tester
to dedicate a significant amount of time to the code, it is often used only to
analyze code that implements high-consequence functions.
Black Box Debugging
Black box debugging
24
is a technique to monitor behaviors external to the binary
component or system while it is executing, and thereby observe the data that
passes between that component/system and external entities.
Additionally, by observing how data passes across the software’s boundary, the
analyst can also determine how externally sourced data might be manipulated
to force the software down certain execution paths, or to cause the software to
fail. This can reveal errors and failures that originate not in the cloud software
itself, but are forced by the external entities with which it interacts, or by an
incorrectly implemented API.
Interoperability Testing
Interoperability testing evaluates whether a cloud application can exchange data
(interoperate) with other components or applications. Interoperability testing
activities determine the capability of applications to exchange data via a common set of exchange formats, to read and write the same file formats, and to
communicate using the same protocols. A major goal of interoperability testing
is to detect interoperability problems between cloud software applications before
these applications are put into operation. Interoperability testing requires the
majority of the application to be completed before testing can occur.
Interoperability testing typically takes one of three approaches:
Testing all pairs— This is often conducted by a third-party independent group of testers who are knowledgeable about the interoperability
characteristics across software products and between software vendors.
Testing some of the combinations— This approach involves testing only
part of the combinations and assuming the untested combinations will also
interoperate.
Testing against a reference implementation— This approach establishes a reference implementation, e.g., using the accepted standard, and
testing all products against the reference. In a paper on metrology in
information technology, researchers in the NIST Information Technology
Laboratory state that a typical procedure used to conduct interoperability
Chapter 3 Cloud Computing Software Security Fundamentals 99
testing includes “developing a representative set of test transactions in one
software product for passage to another software product for processing
verification.”
25
One challenge in cloud software component integrati

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

Lỗi tiêmLỗi tiêm là một kỹ thuật được sử dụng để cải thiện mã bảo hiểm bằng cách kiểm tra tất cả đường dẫn mã, đường dẫn đặc biệt là quản lý lỗi mã có thể không được thực hiện trong cuộc thử nghiệm chức năng. Trong thử nghiệm phun lỗi, lỗi được tiêm vào các điện toán đám mây phần mềm mô phỏng không chủ ý người dùng lỗi và cố ý tấn công ngày Các phần mềm thông qua môi trường của nó, và cuộc tấn công vào môi trường chính nó.Nguồn mã lỗi tiêmTrong tiêm lỗi mã nguồn, thử quyết định khi môi trường lỗi nên được kích hoạt. Các thử nghiệm sau đó "công cụ" nguồn mã bởi Phòng Không intrusively chèn thay đổi vào chương trình phản ánh dữ liệu thay đổi môi trường đó sẽ là kết quả của những lỗi.22Mã nguồn instrumented là sau đó biên soạn và thực thi, và thử nghiệm quan sát cách thực hiện của phần mềm nhà nước thay đổi khi các phần instrumented mã được thực hiện. Điều này cho phép thử để quan sát những thay đổi an toàn và toàn bang trong phần mềm do những thay đổi trong môi trường của nó.Thử nghiệm cũng có thể phân tích như thế nào phần mềm cloud nhà nước thay đổi do một lỗi tuyên truyền thông qua các mã nguồn. Loại phân tích là thường được gọi là lỗi tuyên truyền phân tích, và liên quan đến hai kỹ thuật của nguồn mã lỗi tiêm: mở rộng tuyên truyền analysisand giao diện phân tích tuyên truyền.96 chương 3 Cloud máy tính phần mềm bảo mật cơ bảnĐể chuẩn bị cho lỗi tuyên truyền phân tích, thử nghiệm phải tạo ra một cây lỗi từ mã nguồn của phần mềm. Để thực hiện một phân tích mở rộng tuyên truyền, thử nghiệm sẽ tiêm các lỗi vào cây lỗi, sau đó dấu vết như thế nào mỗi tiêm lỗi Lan truyền qua cây. Điều này cho thấy tác động một lỗi cụ thể sẽ có vào các hành vi tổng thể của phần mềm.Giao diện tuyên truyền phân tích tập trung vào làm thế nào những lỗi được tuyên truyền thông qua các giao diện giữa các thành phần/mô-đun và đám mây cấp ứng dụng và môi trường cấp thành phần. Trong giao diện phân tích tuyên truyền, kiểm tra injects một lỗi vào đầu vào dữ liệu giữa các thành phần, xem như thế nào các kết quả lỗi truyền, và quan sát cho dù bất kỳ bất thường mới gây ra. Loại này phân tích cho phép thử để xác định như thế nào sự thất bại của một thành phần có thể ảnh hưởng đến sự thất bại của một thành phần giáp ranh, đặc biệt quan trọng nếu một giáp ranh đám mây thành phần là quan trọng cả cao.Nguồn mã lỗi tiêm là đặc biệt hữu ích trong việc phát hiện những điều sau đây:Incorrect sử dụng các con trỏ và mảngUse nguy hiểm cuộc gọiĐiều kiện RacePhiên bản tiêm của nguồn mã lỗi nên được thực hiện lặp đi lặp lại như phần mềm đang được ghi. Khi mối đe dọa mới (các loại tấn công và xâm nhập kỹ thuật) phát hiện, mã nguồn có thể được tái instrumented với những lỗi mà là đại diện của những loại mối đe dọa mới.Nhị phân lỗi tiêmNhị phân lỗi tiêm là một kỹ thuật phân tích thời gian chạy theo đó thực hiện một đám mây ứng dụng được theo dõi như lỗi được tiêm. Bằng cách giám sát hệ thống gọi dấu vết, một thử nghiệm có thể xác định tên của cuộc gọi hệ thống, các tham số để mỗi cuộc gọi, và Các cuộc gọi trở lại mã. Điều này cho phép thử để khám phá những tên và loại của tài nguyên được truy cập bởi các phần mềm gọi điện thoại, làm thế nào các nguồn tài nguyên đang được sử dụng, và sự thành công hay thất bại của mỗi truy cập. Trong phân tích lỗi nhị phân, lỗi được tiêm vào các nguồn tài nguyên môi trường xung quanh các đám mây ứng dụng. Môi trường lỗi cung cấp thử nghiệm với một số lợi ích:They mô phỏng các kịch bản tấn công thế giới thực và có thể được tự động dễ dàng.They mô phỏng môi trường bất thường mà không đòi hỏi một sự hiểu biết làm thế nào những bất thường thực sự xảy ra trong thế giới thực. Điều này cho phép lỗi tiêm bởi xét nghiệm những người không có kiến thức trước khi môi trường có lỗi đang được mô phỏng.The thử có thể chọn khi kích hoạt một lỗi môi trường cụ thể. Điều này tránh vấn đề thi đua một môi trường đầy đủ trong đó các nhà nước môi trường khi các ứng dụng tương tác với nó có thể không là những gì dự kiến, hoặc có thể không có hiệu quả dự kiến về hành vi của phần mềm.Chương 3 Cloud máy tính phần mềm bảo mật cơ bản 97Nó là giáo phái khó để dự đoán các đầu vào phức tạp phần mềm đám mây sẽ thực sự nhận được trong môi trường mục tiêu của nó. Vì vậy, lỗi tiêm kịch bản nên được thiết kế để cung cấp cho thử nghiệm tốt sự hiểu biết đầy đủ nhất của các an ninh của hành vi, tiểu bang và các thuộc tính của hệ thống phần mềm Tất cả điều kiện có thể hoạt động. Một khi các ứng dụng đám mây đã được triển khai để sản xuất, thử nghiệm có thể sử dụng thâm nhập thử nghiệm và dễ bị tổn thương quét để cung cấp một biện pháp bổ sung của các ứng dụng an ninh tư thế.Nhị phân lỗi tiêm công cụ bao gồm lỗi nhị phân kim phun và brute-lực xét nghiệm. Những công cụ này sẽ hỗ trợ các chức năng phổ biến được tìm thấy ở Các ứng dụng. Ví dụ, thương mại lỗi tiêm công cụ Holodeck(www.securityinnovation.com/ holodeck /) thường được sử dụng để mô phỏng các lỗi trong Các ứng dụng hệ điều hành Microsoft. Holodeck injects lỗi cho phổ biến chức năng tìm thấy trong một môi trường Windows điển hình như sau:Network-ngắt kết nối, cáp mạng không được cài đặt, sai Winsock Phiên bản, đạt đến Winsock nhiệm vụ giới hạn cổng sẵn, mạng là xuốngDisk-thiếu đĩa không gian, dư thừa vòng phòng (CRC) lỗi, quá nhiều fi les mở, đĩa là chống ghi, không có đĩa nằm trong ổ đĩaMemory-không đủ bộ nhớ, sự thất bại để phân bổ, khóa bộ nhớHolodeck cũng hỗ trợ Giám sát một ứng dụng để xem tương tác của nó với môi trường.Phân tích năng động mãPhân tích năng động mã kiểm tra mã khi nó thực hiện trong một đám mây đang chạy ứng dụng, nhãn tester truy tìm các giao diện bên ngoài trong mã nguồn để sự tương tác tương ứng trong thực hiện các mã, vì vậy mà bất kỳ lỗ hổng hoặc dị thường phát sinh trong các giao diện executing được đặt cùng một lúc trong mã nguồn, nơi họ có thể sau đó được cố định.Không giống như phân tích tĩnh, năng động phân tích cho phép thử để thực hiện các phần mềm theo những cách mà tiếp xúc với lỗ hổng được giới thiệu bởi các tương tác với người dùng và thay đổi trong cấu hình hoặc hành vi của môi trường thành phần. Bởi vì phần mềm không phải là hoàn toàn được liên kết và triển khai trong mục tiêu thực tế môi trường, những tương tác và kết hợp đầu vào và môi trường của họ điều kiện về cơ bản được mô phỏng bởi công cụ kiểm tra.Một ví dụ về một công cụ phân tích năng động mã là mã nguồn mở Valgrind (www.valgrind.org), đó là hữu ích trong việc phát hiện quản lý bộ nhớ và chủ đề lỗi. Bất động sản dựa trên thử nghiệmBất động sản dựa trên thử nghiệm là một kỹ thuật phân tích chính thức phát triển tại trường đại học California tại Davis.23Bất động sản dựa trên thử nghiệm xác nhận rằng phần mềm thực hiện chức năng đáp ứng đặc điểm kỹ thuật của nó. Nó thực hiện điều này bằng cách kiểm tra 98 chương 3 Cloud máy tính phần mềm bảo mật cơ bảnthuộc tính bảo mật có liên quan tiết lộ bởi mã nguồn, chẳng hạn như sự vắng mặt của thay đổi trạng thái không an toàn. Sau đó các thuộc tính bảo mật có liên quan trong mã so sánh với phần mềm đặc điểm kỹ thuật để xác định liệu an ninh giả định đã được đáp ứng.Giống như phân tích trực tiếp mã, tài sản dựa trên thử nghiệm yêu cầu tập trung đầy đủ của thử nghiệm và là một quá trình chi tiết theo định hướng. Bởi vì nó đòi hỏi tester để dành một số lượng đáng kể thời gian để mã, nó thường được sử dụng chỉ để phân tích mã thực hiện chức năng hệ quả cao.Hộp đen gỡ lỗiHộp đen gỡ lỗi24là một kỹ thuật để theo dõi hành vi bên ngoài để nhị phân thành phần hoặc các hệ thống trong khi nó được thực hiện, và do đó quan sát các dữ liệu mà Pass giữa các thành phần/hệ thống đó và các tổ chức bên ngoài.Ngoài ra, bằng cách quan sát như thế nào dữ liệu đi qua ranh giới của phần mềm, các nhà phân tích cũng có thể xác định như thế nào bên ngoài nguồn dữ liệu có thể được chế tác để buộc phần mềm xuống đường dẫn thực hiện nhất định, hoặc gây ra phần mềm thất bại. Điều này có thể tiết lộ lỗi và thất bại có nguồn gốc không có trong phần mềm đám mây chính nó, nhưng là buộc bởi các thực thể bên ngoài với mà nó tương tác, hoặc bởi một không chính xác thực hiện API.Khả năng tương tác thử nghiệmKhả năng tương tác thử nghiệm đánh giá cho dù một ứng dụng đám mây có thể trao đổi dữ liệu (interoperate) với các thành phần khác hoặc các ứng dụng. Khả năng tương tác thử nghiệm hoạt động xác định khả năng của các ứng dụng để trao đổi dữ liệu thông qua một phổ biến thiết lập định dạng trao đổi, đọc và viết các định dạng tập tin tương tự, và để giao tiếp bằng cách sử dụng cùng một giao thức. Một mục tiêu chính của khả năng tương tác thử nghiệm là để phát hiện các vấn đề về khả năng tương tác giữa các ứng dụng phần mềm đám mây trước khi Các ứng dụng này được đưa vào hoạt động. Khả năng tương tác thử nghiệm yêu cầu các đa số các ứng dụng phải được hoàn thành trước khi thử nghiệm có thể xảy ra.Khả năng tương tác thử nghiệm thường mất một trong ba cách tiếp cận:Testing tất cả các cặp-điều này thường được thực hiện bởi một bên thứ ba độc lập nhóm của xét nghiệm những người có kiến thức về khả năng tương tác đặc điểm trên các sản phẩm phần mềm và giữa các nhà cung cấp phần mềm.Testing một số các kết hợp-phương pháp tiếp cận này bao gồm việc thử nghiệm chỉ một phần của các kết hợp và giả định sự kết hợp chưa được kiểm tra cũng sẽ interoperate.Testing chống lại một thực hiện tài liệu tham khảo-cách tiếp cận này thiết lập một tài liệu tham khảo thực hiện, ví dụ, bằng cách sử dụng các tiêu chuẩn được chấp nhận, và kiểm tra tất cả các sản phẩm chống lại tài liệu tham khảo. Trong một bài báo về đo lường trong công nghệ thông tin, các nhà nghiên cứu công nghệ thông tin NIST Phòng thí nghiệm nhà nước một thủ tục thông thường sử dụng để tiến hành khả năng tương tác Chương 3 Cloud máy tính phần mềm bảo mật cơ bản 99thử nghiệm bao gồm "phát triển một tập hợp đại diện của thử nghiệm giao dịch trong một sản phẩm phần mềm cho chuyến đi đến một sản phẩm phần mềm xử lý xác minh."25Một trong những thách thức trong đám mây phần mềm thành phần integrati

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

Lỗi tiêm
chích Fault là một kỹ thuật được sử dụng để cải thiện mã số bảo hiểm bằng cách kiểm tra tất cả các
đường dẫn mã, đặc biệt là đường dẫn mã lỗi xử lý mà có thể không được thực hiện
trong quá trình thử nghiệm chức năng. Trong thử nghiệm tiêm lỗi, lỗi được tiêm vào
phần mềm điện toán đám mây để mô phỏng lỗi vô ý của người dùng và các cuộc tấn công có chủ ý vào
các phần mềm thông qua môi trường của nó, và các cuộc tấn công trên môi trường riêng của mình.
Source Code Fault Tiêm
Trong mã nguồn lỗi tiêm, các thử nghiệm sẽ quyết định khi môi trường lỗi nên
được kích hoạt. Các thử nghiệm sau đó "cụ" mã nguồn của phi intrusively
thay đổi cách chèn vào các chương trình phản ánh các dữ liệu môi trường thay đổi
đó sẽ là kết quả của những lỗi lầm ấy.
22
Các mã nguồn trang bị dụng cụ sau đó được
biên dịch và thực thi, và thử quan sát cách các phần mềm thực hiện của
nhà nước thay đổi khi các phần trang bị dụng cụ của mã được thực thi. Điều này cho phép
các thử nghiệm để quan sát sự thay đổi trạng thái an toàn và nonsecure trong phần mềm
kết quả từ những thay đổi trong môi trường của nó.
Các thử nghiệm cũng có thể phân tích như thế nào thay đổi trạng thái của phần mềm điện toán đám mây như là một kết quả
của một lỗi tuyên truyền thông qua các mã nguồn. Kiểu phân tích này thường được
gọi là phân tích tuyên truyền lỗi, và bao gồm hai kỹ thuật của nguồn
mã lỗi injection:. phân tích giao diện truyền analysisand tuyên truyền mở rộng
96 Chương 3 Cloud Computing Phần mềm bảo mật cơ bản
để chuẩn bị cho phân tích tuyên truyền lỗi, máy đo phải tạo một cây lỗi
từ mã nguồn của phần mềm. Để thực hiện một phân tích tuyên truyền mở rộng,
các thử nghiệm tiêm lỗi vào cây lỗi, sau đó dấu vết như thế nào mỗi lỗi tiêm
truyền qua cây. Điều này cho thấy tác động một lỗi cụ thể sẽ có
trên các hành vi tổng thể của phần mềm.
Giao diện phân tích tuyên truyền tập trung vào cách lỗi được truyền thông qua
các giao diện giữa các thành phần / mô-đun và điện toán đám mây ở cấp ứng dụng khác
thành phần và môi trường cấp. Trong phân tích tuyên truyền giao diện, các thử nghiệm
tiêm một lỗi vào đầu vào dữ liệu giữa các thành phần, quan điểm như thế nào dẫn đến
lỗi, tuyên truyền, và quan sát xem có bất thường mới cho kết quả. Đây là loại
phân tích cho phép thử nghiệm để xác định như thế nào sự thất bại của một thành phần
có thể ảnh hưởng đến sự thất bại của một thành phần nước láng giềng, đặc biệt quan trọng nếu một
thành phần đám mây lân cận là hậu quả cao.
tiêm lỗi Source code là đặc biệt hữu ích trong việc phát hiện những điều sau đây:
Incorrect sử dụng con trỏ và mảng
Use các cuộc gọi nguy hiểm
Race điều kiện
Source code lỗi, cần phải thực hiện lặp đi lặp lại như các phần mềm
đang được viết. Khi mối đe dọa (kiểu tấn công và các kỹ thuật xâm nhập) là người mới
phát hiện ra, các mã nguồn có thể được tái trang bị dụng cụ với những lỗi lầm đó là đại diện của các loại mối đe dọa mới.
Tiêm Fault Binary
lỗi Binary injection là một kỹ thuật phân tích thời gian chạy theo đó một đám mây thực hiện
ứng dụng được giám sát như lỗi được tiêm. Bằng cách theo dõi dấu vết cuộc gọi hệ thống,
một thử nghiệm có thể xác định được tên của các cuộc gọi hệ thống, các thông số cho mỗi cuộc gọi, và
mã trở lại của cuộc gọi. Điều này cho phép các thử nghiệm để khám phá ra những cái tên và các loại
tài nguyên được truy cập bởi các phần mềm gọi điện thoại, làm thế nào các tài nguyên đang được
sử dụng, và sự thành công hay thất bại của mỗi cố gắng truy cập. Trong phân tích lỗi nhị phân,
lỗi được tiêm vào các nguồn tài nguyên môi trường bao quanh các đám mây
ứng dụng. Lỗi môi trường cung cấp các thiết bị kiểm tra một số lợi ích:
They mô phỏng các tình huống tấn công thực tế và có thể dễ dàng tự động.
They mô phỏng môi trường bất thường mà không đòi hỏi một sự hiểu biết
làm thế nào những bất thường thực sự xảy ra trong thế giới thực. Điều này cho phép lỗi
tiêm bằng cách thử những người không có kiến thức về môi trường
mà lỗi được mô phỏng.
The thử nghiệm có thể chọn khi nào để kích hoạt một lỗi môi trường cụ thể.
Điều này tránh các vấn đề của một thi đua môi trường đầy đủ, trong đó
nhà nước môi trường khi ứng dụng tương tác với nó có thể không phải là những gì
được mong đợi, hoặc có thể không có hiệu quả dự kiến về hành vi của phần mềm.
Chương 3 Cloud Computing Phần mềm bảo mật cơ bản 97
Nó là sùng bái diffi để dự đoán các yếu tố đầu vào độ phức tạp của phần mềm điện toán đám mây sẽ thực sự
nhận được trong mục tiêu môi trường. Vì vậy, kịch bản tiêm lỗi nên được
thiết kế để cung cấp cho các thử nghiệm sự hiểu biết đầy đủ nhất có thể có của các
an ninh của các hành vi, tiểu bang, và các đặc tính của hệ thống phần mềm theo
tất cả các điều kiện hoạt động tốt. Khi các ứng dụng điện toán đám mây đã được triển khai
để sản xuất, thử nghiệm có thể sử dụng thử nghiệm thâm nhập và quét lỗ hổng để cung cấp một phương pháp đánh giá độ an ninh của ứng dụng.
cụ tiêm lỗi nhị phân bao gồm phun lỗi nhị phân và brute-force
xét nghiệm. Những công cụ này sẽ hỗ trợ các chức năng phổ biến được tìm thấy trong
các ứng dụng. Ví dụ, các công cụ tiêm lỗi thương mại Holodeck
(www.securityinnovation.com/holodeck/) thường được sử dụng để mô phỏng lỗi trong
ứng dụng hệ điều hành Microsoft. Holodeck tiêm lỗi cho phổ biến
chức năng tìm thấy trong môi trường Windows điển hình như sau:
Network- cáp bị ngắt kết nối, mạng không được cài đặt, Winsock sai
phiên bản, Winsock giới hạn nhiệm vụ đạt được, không có cổng có sẵn, mạng bị ngắt
không gian đĩa Disk- đủ, (cyclic redundancy check CRC) lỗi, quá
nhiều fi les mở, đĩa là viết được bảo vệ, không có đĩa trong ổ
Memory- đủ bộ nhớ, thất bại trong việc phân bổ, khóa bộ nhớ
Holodeck cũng hỗ trợ một ứng dụng giám sát để xem sự tương tác của nó
với môi trường.
năng động Mã Phân tích
phân tích mã động kiểm tra các mã như nó thực hiện trong một đám mây chạy
ứng dụng, với các thử nghiệm truy tìm các giao diện bên ngoài trong mã nguồn để
tương tác tương ứng trong mã thực hiện, do đó bất kỳ lỗ hổng
hoặc bất thường phát sinh trong giao diện thực hiện được đồng thời nằm
trong các mã nguồn, nơi họ có thể được cố định.
Không giống như các phân tích tĩnh, phân tích năng động cho phép các thử nghiệm để thực hiện các
phần mềm theo những cách mà phơi bày lỗ hổng được giới thiệu bởi các tương tác với
người sử dụng và những thay đổi trong cấu hình hoặc hành vi của các thành phần môi trường . Bởi vì phần mềm không liên quan đầy đủ và triển khai trong thực tế mục tiêu của nó
môi trường, những tương tác và đầu vào liên quan của họ và môi trường
điều kiện về cơ bản được mô phỏng bằng các công cụ kiểm tra.
Một ví dụ về một công cụ phân tích mã động là mã nguồn mở Valgrind
(www. valgrind.org), đó là hữu ích trong việc phát hiện và quản lý bộ nhớ
bài lỗi.
Property-Based Testing
kiểm tra tài sản dựa trên là một kỹ thuật phân tích chính thức được phát triển tại Đại học
California ở Davis.
23
kiểm tra tài sản dựa trên xác nhận rằng của phần mềm
đáp ứng chức năng thực hiện thông số kỹ thuật của nó. Nó làm điều này bằng cách kiểm tra
98 Chương 3 Cloud Phần mềm máy tính An ninh cơ bản
tài sản bảo đảm có liên quan tiết lộ mã nguồn, chẳng hạn như sự vắng mặt của
nhà nước thay đổi không an toàn. Sau đó, các tài sản bảo đảm có liên quan trong các mã được
so sánh với đặc điểm kỹ thuật của phần mềm để xác định xem sự an toàn
giả thiết này đã được đáp ứng.
Cũng giống như phân tích mã trực tiếp, kiểm tra tài sản dựa trên đòi hỏi sự tập trung đầy đủ của các thử nghiệm và là một quá trình chi tiết theo định hướng. Bởi vì nó đòi hỏi người thử
để dành một số lượng đáng kể thời gian để mã, nó thường chỉ được sử dụng để
phân tích mã thực hiện chức năng hậu quả cao.
Black Box Debugging
Đen hộp gỡ lỗi
24
là một kỹ thuật để giám sát các hành vi bên ngoài để các nhị phân
thành phần hoặc hệ thống trong khi nó được thực hiện, và do đó quan sát các dữ liệu mà
đi giữa các thành phần / hệ thống và các tổ chức bên ngoài.
Ngoài ra, bằng cách quan sát như thế nào dữ liệu đi qua ranh giới của phần mềm, các
nhà phân tích cũng có thể xác định như thế nào bên ngoài nguồn dữ liệu có thể được thao tác
để buộc các phần mềm xuống đường dẫn thực thi nào đó, hoặc gây ra các phần mềm để
thất bại. Điều này có thể tiết lộ lỗi và thất bại mà không có nguồn gốc trong phần mềm điện toán đám mây
riêng của mình, nhưng buộc bởi các thực thể bên ngoài mà nó tương tác, hoặc bằng một
API thực hiện không chính xác.
Interoperability Testing
thử nghiệm Interoperability đánh giá xem liệu một ứng dụng điện toán đám mây có thể trao đổi dữ liệu
(tương thích) với các thành phần khác hoặc các ứng dụng. Thử nghiệm khả năng
hoạt động xác định khả năng của các ứng dụng để trao đổi dữ liệu thông qua một tập hợp chung các định dạng trao đổi, đọc và viết các định dạng tập tin tương tự, và để
giao tiếp bằng cách sử dụng giao thức tương tự. Một mục tiêu quan trọng của thử nghiệm khả năng tương tác
là để phát hiện các vấn đề khả năng tương tác giữa các ứng dụng phần mềm điện toán đám mây trước khi
các ứng dụng này được đưa vào hoạt động. Thử nghiệm khả năng tương tác đòi hỏi
đa số các ứng dụng sẽ được hoàn thành trước khi thử nghiệm có thể xảy ra.
Khả năng cộng tác kiểm tra thường mất một trong ba phương pháp:
Testing tất cả pairs- này thường được tiến hành bởi một nhóm độc lập của bên thứ ba của người thử những người có hiểu biết về khả năng tương tác
đặc giữa các sản phẩm phần mềm và giữa các nhà cung cấp phần mềm.
Testing một số các phương pháp tiếp cận combinations- này liên quan đến thử nghiệm chỉ
là một phần của tổ hợp và giả sử rằng sự kết hợp chưa được kiểm tra cũng sẽ
tương thích.
Testing chống lại một tham chiếu implementation- cách tiếp cận này thiết lập một thực hiện tham chiếu, ví dụ, sử dụng các tiêu chuẩn được chấp nhận, và
thử nghiệm tất cả các sản phẩm chống lại các tài liệu tham khảo. Trong một bài báo về đo lường trong
công nghệ thông tin, các nhà nghiên cứu trong Công nghệ Thông tin NIST
nhà nước trong phòng thí nghiệm mà một qui trình điển hình được sử dụng để tiến hành các khả năng tương tác
Chương 3 Cloud Computing Phần mềm bảo mật cơ bản 99
thử nghiệm bao gồm "phát triển một tập hợp đại diện giao dịch thử nghiệm trong một
sản phẩm phần mềm cho đoạn văn với các sản phẩm phần mềm để xử lý
xác minh ".
25
Một thách thức trong integrati thành phần phần mềm điện toán đám mây