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
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 ?
Comments