Page 150 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes Results: Non-functional Security Testing Is Essential

Most cards tested with the automated test framework (but not all) pass all functional security
tests, which we expect because smart-card vendors are diligent with functional testing
(including security functionality). Because smart cards are complex embedded devices,
vendors realize that exactly meeting functional requirements is an absolute necessity for
customers to accept the cards. After all, they must perform properly worldwide.
However, every card submitted to the risk-based testing paradigm exhibited some manner
of failure when tested with the hostile applet suite. Some failures pointed directly to critical
security vulnerabilities on the card; others were less specific and required further exploration
to determine the card’s true security posture.
As an example, consider that risk analysis of Java Card’s design documents indicates
that proper implementation of atomic transaction processing is critical for maintaining a
secure card. Java Card has the capability of defining transaction boundaries to ensure that
if a transaction fails, data roll back to a pre-transaction state. In the event that transaction
processing fails, transactions can go into any number of possible states, depending on what
the applet was attempting. In the case of a stored-value card, bad transaction processing
could allow an attacker to print money by forcing the card to roll back value counters while
actually purchasing goods or services. This is called a “torn transaction” attack in credit-
card risk lingo.
When creating risk-based tests to probe transaction processing, we directly exercised
transaction-processing error handling by simulating an attacker attempting to violate a
transaction—specifically, transactions were aborted or never committed, transaction buffers
were completely filled, and transactions were nested (a no-no according to the Java Card
specification). These tests were not based strictly on the card’s functionality—instead, security
test engineers intentionally created them, thinking like an attacker given the results of a risk
analysis.
Several real-world cards failed subsets of the transaction tests. The vulnerabilities discovered
as a result of these tests would allow an attacker to terminate a transaction in a potentially
advantageous manner—a critical test failure that would not have been uncovered under
normal functional security testing. Fielding cards with these vulnerabilities would allow an
attacker to execute successful attacks on live cards issued to the public. Because of proper
risk-based security testing, the vendors were notified of the problems and corrected the code
responsible before release.

Questions
1. Explain the automating security testing.

2. Describes the term non-functional security testing is essential.

Self Assessment Questions

6. The worst type of coupling is……………..
(a) data coupling (b) control coupling
(c) stamp coupling (d) content coupling.

7. The desired level of coupling is ……………..
(a) no coupling (b) control coupling
(c) common coupling (d) data coupling.

144 LOVELY PROFESSIONAL UNIVERSITY