Possible Controls
The final steps in the ATASM process build the set of security requirements to achieve the desired security posture. This is the “requirements” phase spoken of earlier. We applied high-level attack methods to each attack surface. It is precisely these attack methods that will suggest the security controls. As has been mentioned several times above, we cannot expect a 1-to-1 mapping of control, of mitigation to attack, though of course, some mitigations will be 1-to-1.
For instance, we’ve already applied the existing authentication to reduce the attack surface at the application layer. As we explored, adding authentication does provide some control, but it also adds a raft of additional attack surfaces. It’s not a panacea; authentication is a piece of a puzzle. Further and importantly, there is the context of this particular authentication; what does it actually add to the defense for Web-Sock- A-Rama? If the store expects to have a large customer base, as big as possible, similar to services such as Facebook™ or Myspace™, identity has to be very inclusive. In these cases, identity is based solely upon possession of a viable email address, and free email addresses are as readily available to attackers as to you, the reader, (not to mention stolen and hacked email accounts). That is, possessing an email address that can send and receive email proves nothing. Think of all the pets who have Facebook accounts. I personally do not know a single dog or cat who actually reads or posts to a Facebook account. Facebook accounts, despite what I believe to be some “best efforts” on the part of the Facebook security team, are easily opened by attackers, just as well as pets, that is, fictitious identities.
In the case of a web store such as we’re using for our example, at purchase time, a credit card or other payment option is required. However, several years ago, in a United States Federal Bureau of Investigation (FBI) presentation, it was mentioned that stolen credit card numbers were 25 cents each on the black market. Apparently, one buys the numbers in lots of hundreds or thousands.
Due to the realities of email impersonation and payment card theft, an authentication based upon these factors isn’t really worth much, which leaves our Web-Sock-A- Rama website without much attack mitigation based upon authentication. Obviously, the organization’s security team will have their hands full with fraud attempts, operationally removing fraudulent and fake accounts as soon as malicious behavior is observed. Still, at account initialization, there isn’t much that can be done. One email address looks an awful lot like another; as long as the email server opens a connection, the address is going to verify as active. The foregoing should bring the security person to the conclusion that attackers will have accounts and will bypass authentication.
For a web store, the authentication is as much about business as it is about security. This is true because a store wants to give each customer as personalized an experience as possible. Please consider the following data in Figure 5.4: “customer profiles and preferences.” The store retains product browsing history, purchases, interests, and perhaps even reviews and other ancillary data. With this data, the store can offer each customer items of possible interest, thus increasing sales and customer retention. In addition, publishing customer reviews gives customers a sense of participation, not only with the store but also with other customers. Allowing one customer to change another’s preferences or profile would be a breach of customer trust. Once authenticated, customers must be only authorized to access their own data, not the data of any other customer.
To be clear, the authentication in front of the store provides little security control. Additional controls are going to be required.
