Week 13 Discussion post

When developing a software or a computer system, good security requirements are essential in

ensuring that the final product will be secure. However, good requirements can sometimes go

bad for various reasons. First, miscommunication between development teams, security teams,

and stakeholders can result in good requirements going bad (Zakaria et al., 2011, p. 203).

Miscommunication may arise when security requirements communicated by the organization to

the software developers are not be clear, concise, or complete. This may lead to

misunderstandings, ambiguity, or misinterpretation of the requirements. Second, changes in the

business environment can cause shifts in budget, schedules, and resource allocation (Schoenfield,

2015, pp.347-348). As a result, developer teams may be forced to overlook certain good security

requirements to ensure that the software development process is completed. Third, the threat

landscape changes over time thus rendering certain security requirements irrelevant.

Additionally, over time the developer and stakeholders can realize that some of the security

requirements are not aligned with the overall security goals, objectives, and policies of the

organization, or with the business processes and systems that the software or system is intended

to support (Antón et al., 2003, p. 969). For instance, the implementation might realize that some

of the security requirements that stakeholders thought were good are either too strict or too

lenient, or that do not address the actual risks and threats faced by the organization thus making

them bad. Lastly, some of the requirements may be too narrow in scope, focusing on only one

aspect of security, such as authentication or encryption, while neglecting other important aspects,

such as access control or auditing.

To prevent this from happening, organizations can take several steps, such as ensuring clear

communication, aligning requirements with business goals, taking a holistic approach, and
continuously updating and reviewing the requirements. In this case, clear communication would

involve communicating security requirements to the software developers using unambiguous and

concise language while alignment with overall organizational and system security goals and

policies would require a thorough risk assessment and comprehensive security architecture

(Antón et al., 2003, p. 975). A holistic approach would cover all aspects of security, such as

confidentiality, integrity, availability, and accountability whereas continuously updating and

reviewing security requirements would help ensure that they remain relevant and effective. By

following these best practices, organizations can develop software and computer systems with

security in mind, while reducing instances of good requirements going bad.

References

Antón, A. I., Earp, J. B., & Carter, R. A. (2003). Precluding incongruous behavior by aligning

software requirements with security and privacy policies. Information and Software

Technology, 45(14), 967-977.

Schoenfield, B. S. (2015). Securing systems: Applied security architecture and threat models.

CRC Press.

Zakaria, N. H., Haron, A., Sahibuddin, S., & Harun, M. (2011). Requirement Engineering

Critical Issues in Public Sector Software Project Success Factor. International Journal

of Information and Electronics Engineering, 1(3), 200-209.