ISACA Journal Blog

 ‭(Hidden)‬ Admin Links

ISACA > Journal > Practically Speaking Blog

The Need for Speed

K. Brian Kelley, CISA, CSPO, MCSE, Security+ Posted: 7/22/2019 3:01:00 PM | Category: COBIT-Governance of Enterprise IT | Permalink | Email this post

In the 1980's movie Top Gun, the protagonist utters the phrase, “I feel the need, the need for speed!” Peter “Maverick” Mitchell was an F-14 Tomcat pilot, an interceptor jet capable of flying more than twice the speed of sound. Fighter pilots love speed. Speed can be the key factor in winning aerial engagements. Speed is often a key factor in any competitive landscape, whether we are talking about fighters in the air, sports or business. Speaking of business, innovation is all about helping an organization develop processes and products that make it more competitive. As a result, innovation must be fast; the faster the better.

For security professionals and auditors, that means maintaining a balance between speed and protection. If we allow our organization to move too fast, beyond the capability of our controls, we incur risk that could be more costly than losing a product race to a competitor. On the other hand, if our processes cause enough delay where we are constantly behind our competitors, we are putting the long-term health of the organization in jeopardy.


Defining the ROI of Automation

Wade Cassels, CISA, CFE, CIA, Jane Traub, CCSA, CIA, Kevin Alvero, CISA, CFE, and Jessica Fernandez, CISA Posted: 7/15/2019 2:57:00 PM | Category: Audit-Assurance | Permalink | Email this post

In his opening remarks to the general session of the Institute of Internal Auditors (IIA) 2018 Midyear Meetings in Orlando (Florida, USA), IIA Global Board Chairman Naohiro Mouri said that throughout his international travels while in office, he rarely heard from audit practitioners about the “pain of automation” despite the oft-cited benefits of automation technologies and their potential to revolutionize the internal audit function. His comments sparked the idea for our ISACA Journal, volume 4, article, "The Pain of Automation." Our goal was to provide some ideas and best practices that might help ease the pain of automation.


Practically Implementing DevSecOps

Taimur Ijlal, CISA, CISSP, CIPP/E Posted: 7/11/2019 2:45:00 PM | Category: Security | Permalink | Email this post

The explosion of DevSecOps has caused a lot of excitement and worry within the cybersecurity community. It is no longer of question of should an organization implement DevSecOps, but rather when and how? While the scope and complexity of DevSecOps may initially seem daunting to security professionals, there are a few important points that can be kept in mind to implement an effective DevSecOps programs that can enable an organization to increase the velocity of their software releases but remain secure at the same time:

  • Remember that tools are your best friend. The speed of DevSecOps makes manual testing/review simply too cumbersome to be effective. Find out which security tools best fit into your delivery pipeline, and work with the teams to effectively integrate them so that your security controls are an integral part of the framework. At a bare minimum, you should be having secure code reviews and automated security scanning for every software deployment.
  • Automate the decision-making process. One of the key things I realized during implementing security controls in DevSecOps is that none of the automated security testing mentioned previously will make any difference if decisions are not made immediately based on their results. Jobs need to intelligently succeed/fail based on security success criteria that the security professionals and developers need to sit together and define. Certain things will be showstoppers for which the developers will need immediate feedback, while others can be fixed later, but this decision-making framework needs to be automated, with immediate results being sent back to all relevant teams.
  • There is no escape from coding. As much as I would like to say that every organization has enough budget to hire dedicated security professionals with deep coding experience, that is simply not realistic. DevSecOps often needs security professionals to roll up their sleeves and dig in to the code to find out why jobs are failing, application programming interface (API) calls are not being triggered, etc., and developers will get frustrated if security professionals are not able to provide answers for such problems. Investing in security training for developers and coding training for security professionals will reap huge dividends in the future and help break down silos, enabling a faster cultural shift to DevSecOps at the ground level.

Read Taimur Ijlal's recent Journal article:


Coincidence or History?

Ian Cooke, CISA, CRISC, CGEIT, COBIT Assessor and Implementer, CFE, CIPP/E, CIPM, CIPT, FIP, CPTE, DipFM, ITIL Foundation, Six Sigma Green Belt Posted: 7/1/2019 3:12:00 PM | Category: Audit-Assurance | Permalink | Email this post

Ian CookeOn 23 October 1969—just a few months after Apollo 11 landed on the moon—the Electronic Data Processing Auditors Association (EDPAA), later to become ISACA, was incorporated. Just six days later, on 29 October 29 1969, the first communications were sent through the ARPANET, the predecessor to the Internet. A coincidence? Perhaps—but ISACA was there.

In 1996, IBM's Deep Blue defeated chess champion Gary Kasparov for the first time, and Windows NT 4.0 was released by Microsoft. In 12 months, the number of Internet host computers went from 1 million to 10 million, and COBIT was released. A coincidence? Perhaps – but ISACA was there.


Patch Management Practice

Spiros Alexiou, Ph.D., CISA, CSX-F, CIA Posted: 6/17/2019 3:11:00 PM | Category: Security | Permalink | Email this post

Unpatched systems represent a very serious IT security threat with potentially extremely important consequences, as documented in a large number of high-profile breaches that exploited known unpatched vulnerabilities. Since these vulnerabilities are known, not just to attackers, but also to system administrators, and since patches exist, it is on first look surprising that unpatched systems even exist. The reality, however, is that patching is not that simple: Because of interdependencies, it must be verified that the patch is compatible with everything else in the system, e.g., an operating system patch must be compatible with the applications and databases running on top of the operating system. Sometimes, they are not, as manifested, for instance, in the recent Spectre and Meltdown vulnerability, where some application providers explicitly warned against patching. Verifications mean testing by other vendors, and this may not be a high priority for the application vendor, with an answer or full solution sometimes coming with the next release. Today’s organizations typically employ a large number of systems and applications, and making sure all of them are patched promptly is not automatic.

<< First   < Previous     Page: 1 of 89     Next >   Last >>