Skip to main content

SDLC - Infosec and the SDLC - Where to implement Security

The traditional way to develop software is to write down the Software Requirements Specification (SRS) document and then bring it to the table for security to review them. It is always an after thought and it involves lot of selling from the Information Security Team to do the selling to make a few changes to the SRS.

Many a times when the SRS is written down and the Business Analyst picks up the nuances of the application to document the SRS, a major area not covered is Information Security. We have also found instances where the Information Technology folks define security in such a way that it suits their platform or technology they are comfortable with.

The major trouble with this model is that the Business Analyst is so intent on the functionality of the application and the Technologists – Architect and the Project Manger are intent on building an application in time and with budgets, that InfoSec issues are on the back burner.

The approach that is best recommended is for the Information protection and requirements to come from the business owner. We are often asked why the business owner, often by the architect, but the fact is, they as the user of the application know what is best and what needs to be protected. The Business owner also owns the application and he is the best judge as to the reasons for the application to exist in the first place. They generate the data, they manipulate the data, they understand and know what they are capturing or being used in the application. Is it not obvious they should know how to handle the information?

The business analyst needs to understand this main reason for getting the business owner to specify the requirements and capture the requirements, based on these inputs it would be prudent for the architect and the Information Security Architect to work with the available technologies and bring out the best with all the features required by the business.
The major advantages in getting the business owner involved is, this eliminates unnecessary work flows that are a product of technology and not business. The work flows are clearly understood by the business user as he is the one who had put down the specifications.
So what are the major specifications that come from the business – It does not matter how the technology would achieve the requirements , the specs may include
  • Who has access to the application, what are the roles for the application?
  • What are the approval work flows?
  • What are the requirements for audit trails ?
  • What are the requirements for identification ?
  • What are the audit trails required for reporting ?
  • What are the Security flags that needs to be notified ?
  • What are the controls required in certain fields ?
Some of the above questions are to be documented in the SRS. If the SRS does not have it , very likely that they would be ignored during the design phase. This would ensure the application is secure as well as reduce the costs of re-factoring the application later.

Labels

Labels:

Comments

Post a Comment

Popular posts from this blog

Malware Damage - It is real and you need to be ready ...

  Malware, short for "malicious software," is any software intentionally designed to cause harm to computer systems, networks, or devices. Malware can take many forms, including viruses, trojan horses, worms, ransomware, spyware, and adware, among others. The dangers of malware are numerous, and it is crucial to protect yourself from malware to avoid serious consequences, such as: Data theft: Malware can be designed to steal personal information, such as bank account details, social security numbers, and login credentials. Once this information is stolen, it can be used for identity theft, financial fraud, and other malicious activities. System damage: Some malware can damage your computer system, causing it to crash or malfunction. This can result in lost data, system downtime, and costly repairs. Financial loss: Malware can also be used to extort money from victims. For example, ransomware can lock down a victim's computer and demand payment in exchange for the decrypti...
Post a Comment
Read more

CIO Questions answered - Your comments welcome - The reflections of the inner self

Briefly describe the typical size and organization of an IT team that you have managed. Include the division of responsibilities, how you track progress, etc. My experience ranges from me working independently, mainly to maintain my independence when I perform audits to managing a team of more than 25 - 100 consultants in various roles. I have handled multiple projects simultaneously where we have multiple consultants (typically from five to ten) working on multiple projects. We have used a set of tools to specifically monitor progress as well as the milestones. The projects involved were simple roll out of products (Microsoft Active Directory Domain Builds, Log Consolidation, Vulnerability Management) in line with product specifications to complex integration of systems that involves building multiple SoA interfaces for healthcare applications. For a successful project there needs to be proper delegation, personally I believe a person can deliver if he is not micromanaged, identifyi...
Post a Comment
Read more

A Roadmap to move from Cloud to In premise - The reverse migration -- Is Cloudflation at myth?

 Cloudflation as a term is being used and talks on the spiralling cost of cloud bills for an organization. The easily available and provisioning options leads to workloads that run for no reasons, orphaned accounts and a gamut of costs that are accrued by multiple departments without much of an oversight. There is a trend to reduce the workloads and have a semblance of order. It is imperative that we have plans that helps to reverse the migration to cloud and bring back some of the workloads that might work cheaper to run local. Is there a roadmap to achieve this goal? A few pointers in this direction A roadmap for moving from the cloud to in-premise computing should include the following steps: Assess current workloads: Assess the current workloads that are running on the cloud and determine which workloads would be most suitable for in-premise computing. Identify in-premise infrastructure: Identify the in-premise infrastructure that will be needed to run the identified workloads....
Post a Comment
Read more