All Isaca CISA certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the CISA Certified Information Systems Auditor practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Lesson 4

1. Media Disposal Process

At some point, we're going to have to throw things away. We're going to have to dispose of old hard drives, old tapes, old documentation, old equipment, and old disks. How do we deal with media disposal? And the IS auditor is particularly interested in media disposal because once we throw something away, it's out of our control. People could go dumpster diving, or they could retrieve stuff that some government agencies do not allow. like when they donate computers to charity or something. The hard drives can't be part of it. And you have to realise that it's not just going to be the hard drives; firmware on motherboards and firmware on other things will basically give away the configuration of a system. And you might not want to give away that kind of information. There's also documentation: there are tapes, there are disks, there are hard drives, and there is removable media. All these things we have to worry about Let's talk about backups.

For one thing, when I make a backup, it's usually unencrypted, which means if someone grabs a copy of that backup, they can just restore it, and now they see all the data. How are you going to destroy old backups? Not only store them safely, but how are you going to get rid of them? How are you going to get rid of old tapes that are so worn out you don't dare use them anymore or you don't want to use them anymore? We need a way of destroying those effectively as well, effectively. How about hard drives that are so old and yet they might contain information that is personally identifiable, confidential, secret, or whatever else you can discern? meaning you can put a hard drive on, essentially, a strong magnet to wipe it out.

But the only truly, truly secure way is to destroy the hard drive so that the data can't be recovered. Because a hard drive is basically a metal platter, It'll have like two or three little platters that spin on a spindle, and there are these little arms that read that move across the surface of this platter. And even if you erase, there's going to be a magnetic imprint underneath. And with the right kind of equipment, even if you were erased many times, you might still be able to retrieve the information. So at what point is it acceptable to just simply degauss, erase, or certainly just format something so that you don't have information leakage? So you have to consider all these things.

You might have data that is not stored in a normal database that was backed up. You may have stacks of surveys. You may have paper data. You may have tapes, disks, or something like that. You may have data that is the result of marketing campaigns and consumer surveys. And some of that will probably contain personal, identifiable information or possibly confidential information. Certainly consumer habits, which we're trying to protect with privacy awareness, so what are you going to do with those things? You're just going to throw them in the dumpster? Are you going to shred them or what? In your security policy, there's got to be a disposal procedure, and there has to be a way of identifying what can just be tossed in the trash as opposed to what has to be shredded as opposed to what has to be destroyed as opposed to what can just simply be wiped out. And the IS auditor wants to see if these procedures were upheld or if there were any in place. Is there a disposal policy?

You might have situations where the tapes containing this information are starting to get worn out, but by service level agreement, by regulation, by contract, or for whatever reason, we need to keep this information. But the tapes are starting to get worn out. So we're going to transfer from one to another. Now, what do you do with the old one? How do you destroy that? So these are all things that you have to be aware of. There needs to be a policy in place for securely shredding or destroying stuff that is too confidential or too secret to just let out. And then, how do you properly dispose of everything else?

How do you properly transfer data when media starts to wear out? So the IS auditor needs to look at all of these things. There can be a number of triggers that will occur when we dispose of media. and we can see some examples over here. There's been a major technological change, including obsolescence. Nobody uses eight-track tapes, and nobody uses Betamax anymore. We went to VHS. Nobody uses five-and-a-quarter-inch floppies anymore. Nobody uses floppies. And so, pretty soon, I mean, nobody uses this or that or the other. So it's time to move the data from one type of media to another. I mean, if you are trying to preserve something archivally, you may also say in your archives, "You know what, we've got these tapes, and they only run on certain kinds of tape drives." We're going to have to move this to another kind of storage medium because we want to keep the archive of it, but we have no way of replaying this thing.

So obsolescence in technology could be one reason. Or you may have a regulatory or compliance requirement that will require us to shred, move, or restore something, or the client wants to use a different vendor, a different version, or a different technology. Now, to comply with what the client wants, we need to take it off of the tape and put it on a USB drive or something; or just the asset, the tape or whatever, is just naturally expiring, or these drives are naturally expiring, and the media is naturally expiring. I remember when the Compact Discourse came out, and it was originally thought that the usable life of those things would be maybe about ten years. We know that they have lasted longer than that. But then there have also been cases where we have lots of stuff on tape and either we don't have the means to play those tapes back or the tape itself is starting to deteriorate.

So any of these things could trigger the need for moving information off-site and destroying old media. So the IS auditor, when looking at the disposal process, wants to be looking at this checklist here. Did the disposal process address all of the separate goals of the disposal policy? And when we did the review, were all of the separate goals addressed? Did the disposal guidelines get published? Were they available? Did people know how to dispose of certain things? Were the guidelines specific? Did they specify the proper time period for when we should dispose of things and how long a document should live? Did the policy specify which documents can be discarded as opposed to which documents have to be shredded? Did we comply with any regulatory requirements saying, "You've got to keep this thing for two years or seven years"? You've got to realise that putting stuff in the recycle bin isn't any safer than throwing paper in a trash can. You know, the recycle bin, we can go right into it.

Even if you permanently delete something, we can still retrieve data off of drives. If we hire a third-party vendor to safely dispose of our stuff, if they don't do their job, we're still responsible because, ultimately, it was our job to get rid of this stuff safely. The fact that we outsourced it to someone doesn't mean we can outsource the responsibility. Now, we may have a contract that helps share the responsibility, but we're the ones who are going to get into trouble. And if we're going to reuse storage media like USB drives, did we thoroughly wipe that stuff clean? Is it considered acceptable now? Or if we're going to reuse hard drives, was it thoroughly wiped clean? Or if we're just going to give them away and dispose of them, did we thoroughly wipe them clean? And then, are there any additional government standards that are being met for our particular organization, our business, or our particular location? And with that, that is the end of all the topics for lesson four.

2. Post Implementation Review

We've seen how to develop software or a system. We've seen the development methods and the development lifecycle. Now, how about the maintenance? Part of the SDLC has been rolled out into production. We're not done. We need to have a post-implementation review. We need to have periodic reviews. We'll need to do some maintenance. And at some point, this system that we spent time and money creating too will get phased out and replaced by a new one.

So there will be a way to decommission this and dispose of even the software, hardware, code, documentation, etc. So these are things that we have to be looking at after we've successfully rolled out whatever this new system is in our post-implementation review.

Why would we want to have a post-implementation review? Well, did this thing really do what we thought it would do? I mean, did this actually give us what we had hoped for? Are there any lessons learned? Were there any weaknesses that turned up that we really should address right now, maybe in a minor release or a patch or something? Do we have ongoing problems, and how well has it been adopted? Do we need to follow up with training or are there some patches, tweaks, or configuration changes we need to make? So this is why we need to look; we need to gather metrics on the performance and acceptance of this thing. So our post-implementation review objectives and our auditors need to understand these objectives.

Here's a good checklist: The review should answer questions. Did this really meet our requirements, really? Was there any measurable return on investment? Do we have any recommendations that might address some issues, weaknesses, or inadequacies? Is there any plan to meet those recommendations? It is so frustrating to have a retreat. I mean, I've even been on retreats where the organisation had the partners and the vendors and the governmentpeople and whoever, okay, what can we do now? And we have breakout sessions, and we come up with documented retreats or documented recommendations, and nothing's done; nothing is acted on. That is so disappointing, and it's so bad for morale. So was there ever any plan to address their recommendations? If nothing else, that's fabulous.

These things we just can't do right now because of the budget or this or that constraint, but we certainly can do those things, or if nothing else, even acknowledge them. Okay, thanks, folks. But you know, people don't want to hear empty promises. They want to see some action. And if their recommendations aren't taken into account, they need to understand why. When you're working on a project, leaving people in the dark is the surest way to get them to not cooperate later. So anyway, was there any plan for acting on the recommendations one way or another? And did we use the appropriate methodologies, standards, and project management tools at all?

Now, our methods for the post-implementation review—getting staff and customer requirements questionnaires—are terrific. Going and interviewing people, collecting metrics, looking at the effectiveness of the controls and the completeness of the documentation, and also how good the performance is and how good the post-implementation support is, These are all things we can do to review after this thing has been rolled out. In some cases, you can have something called an EAM, an embedded audit module that basically collects performance data. Most major vendors, such as software vendors, have some ways to collect logs. Certainly all operating systems have ways of collecting performance logs. And so we can have maybe software or tools embedded in an application or in an operating system or in some other system we've rolled out just so we can look at performance data. I mean, you can get monitoring consoles with varying budgets, from free to very expensivemonitoring consoles to monitor performance.

And then we can look at, well, before we ran at this level, now we're running at this level, or we're running even, or we're down. And why is that? So whenever you can automate some of this data collection, it's very, very helpful. Especially when you're trying to get things like event logs and things like uptime and things like system stability. Automated collection tools are excellent for that. or things like available bandwidth. These are the kinds of things that you'll want. Automated collection tools that you can just look at on a console or print out a report So when we are doing the post-implementation system review, here are some things that the IS auditor needs to keep in mind. Did the system requirements actually get achieved? When we review this, we will see that we went through all this time in trouble and had requirements.

Did we actually meet the requirements? Did the feasibility studies cost more than the benefits that were determined at the beginning of the project? Were they correctly measured and reported to management? Were there any change requests? And we want to look at those change requests to see what kinds of changes were required and how they were dealt with. Are there controls that will protect the implementation, function, and performance of this and help mitigate the risk? Are they functioning adequately? Are there any error logs? Let's take a look at the error logs to indicate that the testing was maybe not thorough enough. And we want to see the inputs and the outputs to see if the data went in like this. Did it come out correctly like that? If we took all kinds of information here, did the reports come out as they should? So these are the things that the auditor is going to want to look at.

3. Periodic Review

We talked about the review process immediately after the successful deployment of the system or the software that we developed. How about the periodic review? Why do we have periodic reviews? Well, we need to make sure that this thing that we so successfully deployed and that's working is still working and that there haven't been any untoward changes. Maybe the environment is shifting a bit and this thing needs to be tweaked or updated because it worked great then, but it's not quite keeping up with a changing need, demand, or environment. How about the change control? Was that done effectively or inappropriately? And when we did come up with recommendations from the post-deployment review, have they been implemented? So these are things that we need to periodically check. How often? Well, it kind of depends. At least once a year, maybe every six months if you can, or, if you're really lucky, every quarter.

But that's probably not very likely. So we have to periodically review how well this new thing is working. When we're talking about the periodic review, we might run into some communication challenges. So we have to have the users and developers on board. We need to go ask them: Is this thing still meeting your requirements? Is it still meeting your objectives? What about the component developers or infrastructure people? How is this thing still running for you? We need to get their input. When we do the periodic review, we shouldn't just trust what the manager says. We should look at logs, and we should get input from the people who use it and input from the people who developed it as well. As we do periodic reviews, whatever that time period is, we'll want to be able to see audit trails. We'll want to be able to compare well. We saw that this problem was reported right during the pilot. We saw the same problem reported during release.

We saw the same problem reported during this periodic review, so we can call it to attention and see if we can tie the problem to a loss of productivity, a loss of effectiveness, a loss of income, a loss of competitiveness, or something else that really helps get management's attention. So you want to be looking at audit trails and getting the whole story. Okay, so back at this date, we had this much information later. We had this much later. We had this much, so we'll want to be able to show the audit trail. And we'll want to be able to see the audit trail. This has been going on for, say, two years. And we've been reported every quarter when we're doing a periodic system review. Also, quality assurance is always going to play a role. Quality assurance had to be there during the SDLC itself and during the development process itself.

And quality assurance has to be here in the post-implementation phase while this thing is in production to always make sure that this thing is meeting objectives. We're enforcing standards and things like naming conventions. This thing is producing something that is correct or valid. It's producing data that is valid. It doesn't have any errors. So the quality assurance process needs to always be involved, even after we have rolled this thing out. Different QA methods We've got some examples here. Failure testing. I love to stress-test applications and systems. I love to run load simulators until they break just to see how they behave. I love to run load simulators to the point where the operating system can no longer even report its processes. It's just stopped responding to monitoring tools, and we're just seeing how far we can push it because this is what we need to know about real life and what it's going to be like. So we can failure test and stress test. We deliberately push it till it fails or breaks, and we're trying to find out its total limits and its upper and lower limits of operation.

Also, when we're doing QA, we want to make sure that we keep those failures within an acceptable number. So we'll want to have some control over the status, the statistics of the number of failures. And then, of course, we may have to do regression testing if we do a patch or a fix. Let's run the test again to make sure that we didn't break something else. We didn't introduce new errors. The application you need to keep safe copies of, and if you bought this thing, keep the licences too. I've got terrible stories of managers who went to clean out closets, saw boxes of stuff, and threw it away. didn't realise that they were throwing away the licences of all of the software that they had bought and deployed. And then they had to provide the licenses, which they couldn't do, and they couldn't prove that they owned that stuff because they didn't bother to register either. And so now they had to pay the licencing fee twice and pay fines.

So with the media, we need to make sure that there is a media library and that it is clean. Good copies always exist in a known place, safely stored, where it's clean and dry, not too humid, not too hot, not too dusty, and not in direct sunlight. And all of these things to keep the media clean, safe, and stacked like this. not stacked like this. And we'll need that clean media in case we have to reinstall something or recover something. And of course, we need to make sure that there's only authorised access to this clean media. We have a media custodian who keeps it all locked up. And it could be as simple as just the manager keeping it locked in a storeroom with other equipment, or some part of the IS department keeping clean copies. What we have to be careful of with licenced stuff is that the IS department, wanting to have the convenience of everyone having a copy, will start duplicating the disk. And so one thing, I suppose, if you have a volume license, but if not, then you have to be careful, especially if they start using up licenses, and it's one of those things where the licence then gets registered online with the vendor, and now you can't use that licence when a legitimate user actually needs it.

So you have to have some control over the installation media. So when we are doing a system review of the SDLC, when we're auditing, there are two major things, and there's a very nice checklist we can take a look at here: the project management activities. So if I'm going to be auditing, if I'm going to do the system review, I'll look at the adequacy of the oversight, the risk management, the issue management, the cost management, the planning, and the dependency. management, the reporting of the processes to senior management, change control, the management of the stakeholders, and their participation. How processes were signed off in the SDLC document documentation Also, for each phase, I wanted to see the deliverables that were organised by SDLC phase. So I want to see documentation for the concept and initiation, the requirements, the design, the development, the testing, the deployment, and the post-deployment, and we'll want to see the schedule that focuses on producing the deliverables organised by date, as well as any economic forecast for this life cycle phase, including the cost of everything involved with this. So these are all things that we're going to be looking at when we're auditing the SDLC. So when we are performing periodic system reviews, we've already deployed this thing.

We had a post-deployment review, which was good, and six months later, or a year later, or a quarter later, we're doing a periodic review. We need to meet with not only the users but also the dev staff, the people who developed it, or the system administrators, or the it staff that developed the system. Make sure that the main objectives, the components, and the user requirements are still met. We want to try to participate in any post-implementation reviews. We want to be involved in that, and of course we need to see who was involved. We want to, where applicable, review the project management activities, review the documentation, and make sure that the user and customer requirements were met and signed off on. Make sure that test management was done properly if they applied everything. So that ultimately this thing supports the business objectives, and I want to see test results too, if possible, if they exist. I also want to see any controls to help manage and mitigate the risk associated with this new system that we've deployed.

4. System Maintenance

Make sure that we know the standards, best practices, guidelines, and all of the relevant processes that we're looking at. So here is an excellent checklist for the Sisa that is evaluating the maintenance process.

Isaca CISA practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass CISA Certified Information Systems Auditor certification exam dumps & practice test questions and answers are to help students.