The “Modular Mayhem” section of the reading discussed modular programming and also the risks of code reuse. I found the most interesting discussion to be about the benefits and risks of code reuse. It can save time and resources. However, it can undermine the security of your program. Something that likely gets overlooked by slopping developers is that any internal libraries or APIs that you’re calling can be a concern. Internal libraries were often created before security was even thought about much so there may be many vulnerabilities. Developers can research vulnerabilities for any public libraries or APIs they will use. Code reviews can be done for internal code. The big idea is that you need to know and evaluate the entire attack surface for the system and application, which can be increased by libraries, modules, and APIs called from other sources. Those risks need to be mitigated.
In this week’s reading assignment, an interesting takeaway that I think is important to mention is about a system development methodology. According to the textbook, a systems development methodology is a structure that an organization uses to plan and control the development of information systems and software and new business applications. The textbook also mentions three different types of models that can be used for a system development methodology. These three models are known as Traditional waterfall, V-shaped, and Iterative. According to the book, the traditional SDLC (waterfall) model and variants of the model normally involve a life cycle verification approach that ensures that potential mistakes are corrected early and not solely during final acceptance testing. V-shaped models focus on the relationship between development phases and testing levels. V-Shape models are the most vague testing, the unit test and occurs immediately after programs have been written in code. And the iterative model is a cyclical process in which business requirements are developed and tested until the entire application is designed and tested to be launched. During each iteration, the development process goes through each phase, from requirements through testing, and each subsequent cycle incrementally improves the processes and efficiencies of the system.
Elias, I agree that the various types of system development methodologies are important takeaways of the reading. I think it is especially important to understand the pros and cons of each methodology type, especially from the lens of a systems developer. For example, many software development projects use the iterative model in order to quickly meet evolving customer needs. However, this model may not be satisfactory for a systems development project that has clearly defined requirements, as the iterative nature may become redundant.
The one of key points in CISA Manual Chapter 3, “Control Identification and Design” that I am interested in is how to manage input authorization. According to Chapter 3, there are several types of authorization, including signatures on batch forms or source documents, unique passwords, and terminal or client workstation identification. In order to secure data and information, authorization of input can ensure that only the authorized data will be processed into the system. It also needs to have controls, which maintain the authorized data is unable to make changes. While assigning a file to someone, we can set up a password to protect the file from not being modified. Additionally, the terminal identification number can be used here to monitor the users’ access to the system. It can limit input to specific terminals or workstations. In my opinion, these methods of authorization can prevent some fraud, such as stealing confidential information.
Cami,
I agree with your comments. Having the proper authorization and authenticity is an interesting topic. I like how you mentioned that unique passwords, client workstation identification are controls that would assist in properly authorized users. I also agree that the methods of authorization discussed can be used as fraud mitigation techniques
Auditors should have knowledge of how the systems are designed. We should be able to identify and understand controls designed to ensure the authorization, accuracy and completeness of data input and output. It is also requires that IS Auditors have adequate knowledge of the control techniques and how each may be evidenced as reports, logs and audit trails. The input authorization ensures all transaction have been authorized and approved by management. The controls ensure the integrity of the data and can be verified by various accuracy and completeness checks. This facilitates error reporting and handling. Errors can occur due to duplication of transaction and inaccurate data entry. Correcting the data should go through the normal process and must be verified, authorized, and reentered. Input error handling can be processed by rejecting only transactions with errors, rejecting the whole patch of transactions, holding the patch in suspense, and accepting the batch and flagging error transactions.
While reading the CISA materials about control Identification and Design I was able to easily relate to the topic when thinking about an ERP system. There were multiple potential controls listed that could be applied at data entry, approvals, transaction processing and lastly output validation. these controls made sense as I thought about the type of business processes ERP systems support.
However, I had to really think about how some of these controls might be applied to other systems. E.g. a geographic mapping or addressing system – how would you control data inputs? How would you control approvals (are there approvals)? How do you control outputs? I guess you can do field level validations (numbers only in address and zip codes etc). Has anyone seen a good comprehensive list of potential controls mapped against different system types?
The methodology aspect can be crucial, I think its important to first make sure the one chosen makes the most sense for the business case. Each one has its own strengths and weaknesses and works effectively in different situations. When choosing a development methodology, think about combining the elements of each method that work best for your team and your current project. By doing that, you can create a development methodology that will get you to production securely and efficiently.