ABSTRACT
It would be extremely difficult to find a building architect who would engage in building a skyscraper without a blueprint or a chef who will indulge in baking world-famous pastries and cakes without a recipe that lists the ingredients. However, we often observe that when software is built, security requirements are not explicitly stated. ˜e reasons for such a modus operandi are many. Security is first and foremost viewed as a nonfunctional requirement and in an organization that has to
deal with functional requirements owing to the constraints posed by budget, scope, and schedule (iron triangle constraints), security requirements are considered to be an additional expense (impacting budget), increased nonvalue added functionality (impacting scope), and were time-consuming to implement (impacting schedule). Such an attitude is what leaves secure software requirements on the sidelines. Second, incorporating security in software is often misconstrued as an impediment to business agility and not necessarily as an enabler for the business to produce quality and secure software. Secure software is characterized by the following quality attributes:
◾ Reliability: ˜e software functions as it is expected to. ◾ Resiliency: ˜e software does not violate any security policy and is able to
withstand the actions of threat agents that are posed intentionally (attacks and exploits) or accidentally (user errors).
