CA Final classes

ISCA - CA final classes @ Wizard will start from December 26th,2012 .
Duration : 30 Days
Timings : 6.15 pm to 9.00 pm
Faculty : Praveen Jain.
For further details contact WIZARD - the school of CA Studies . 
Ph no : 9866365700 

Plz spread the word..

CA Final Class @ ICAI - Hyderabad Chapter

CA Final ISCA Classes @ Institute of chartered accountants of india (ICAI) -
 Hyderabad Branch from 26th August 2012.

Timings : 7.00 a.m to 1.00 p.m . 

Duration : 5 Days. [ Short Version :-) ]

Faculty : Praveen Jain . 

For further details contact ICAI - Hyderabad Branch - 040 30638600

Please spread the word friends.

ISCA Classes

Hi friends,

ISCA - CA final classes @ Wizard will start from September 6th , 2012 .
Duration : 25 Days
Timings : 6.30 am to 9.30 am
Faculty : Praveen Jain.
For further details contact WIZARD - the school of CA Studies . Ph no : 9866365700 

Link to download Chapter 5 Amendments

https://docs.google.com/open?id=0B8VHj6UrN66vcTFNemMyVUZXSXc

Password to open the file :   praveenjain

ISCA - made easy - Second edition ( Cover Page )

ISCA - made easy

Friends,

Second edition of the book "ISCA - made easy" for CA final exam authored by me is in book stores & at Wizard now..

Relevant changes / amendments are made . 

Also past years question paper , weight-age scanner & tips for writing exam are introduced in the new version.

Hope it will be useful ..... 

Happy learning & all the best for exams... :-)

SALIENT FEATURES OF THIS BOOK

1.  Concise, yet covering whole syllabus, making it easy for the students to quickly revise the subjects even during the exams.
2. Presented in a lucid & understandable language.
3. States learning objective at initiation of chapter
4.  Module wise presentation.
5.  No compromise is done in terms of Font size.
6. Updated.
7. Point wise presentation.  
8. Tutorial note: Author’s note – to make the text user-friendly & provide gist about the content.
9.  Includes Past years question papers (Blast from the past), Exam tips & Weightage Scanner.

Amendments in ISCA

Also there are little changes in Chapter - 2 . But  major part is only deletions . 

Following are the additions :

Chapter 2 – SDLC

Agile Methodologies

Basic Principles :

Following are the key principles of this methodology:

©  Customer satisfaction by rapid delivery of useful software;

©  Welcome changing requirements, even late in development;

©  Working software is delivered frequently (weeks rather than months);

©  Sustainable development, able to maintain a constant pace;

©  Close, daily co-operation between business people and developers;

©  Face-to-face conversation is the best form of communication (co-location);

©  Projects are built around motivated individuals, who should be trusted;

©  Continuous attention to technical excellence and good design;

©  Simplicity;

©  Self-organizing teams; and

©  Regular adaptation to changing circumstances.

Strengths

©  Able to respond to the changing requirements. ( i.e., Adaptability)

©  Investment in time and efforts are saved.

©  Guesswork is eliminated. ( Due to face to face communication and continuous inputs from customer representative)

©  The documentation is crisp (decisive) and to the point to save time.

©  The end result is the high quality software in least possible time duration and satisfied customer.

Weaknesses

©  Difficult to assess the efforts required at the beginning of the SDLC in case of big projects.

©  Lack of emphasis on necessary designing and documentation.

©  Agile increases potential threats to business continuity and knowledge transfer since verbal communication with the customer is emphasized rather than on documentation.

©  Agile requires more re-work because of the lack of long-term planning and the lightweight approach to architecture.

©  The project can easily get taken off track if the customer representative is not clear about the final outcome that they want.

©  Senior programmers are capable of taking the kind of decisions required during the development process. Hence, it has no place for newly appointed programmers, unless combined with experienced resources.  ( i.e., Experienced programmers are required)

Auditors’ Role In SDLC  ( Amendment)

The audit of systems under development can have three main objectives:

ü  To provide an opinion on the efficiency, effectiveness, and economy of project management;

ü  To assess

©  the extent to which the system being developed provides for adequate audit trails and controls to ensure the integrity of data processed and stored; and

©  the controls being provided for the management of the system's operation.

1.    For the first objective to achieve,

·         Auditor will have to attend project and steering committee meetings and examine project control documentation and conducting interviews.

·         This is to ensure what project control standards are to be complied with, (such as a formal systems development process) and determining the extent to which compliance is being achieved.

2.    For addressing second objective,

·         Auditor has to examine system documentation, such as functional specifications, to arrive at an opinion on controls.

·         Auditor's opinion will be based on the degree to which the system satisfies the general control objectives that any Information Technology system should meet.

·         A list of such objectives should be provided to the auditee.

3.    The same is true for the third objective, viz. system's operational controls.

·         Auditor should provide the a list of the standard controls, over such operational concerns as response time, CPU usage, and random access space availability, that the auditor has used as assessment criteria.

4.    Auditor may adopt a rating system such as on scale of 1 to 10 in order to give rating to the various phases of SDLC.

5.    After deriving such a rating for all the phases, the auditor can form his/her overall opinion about the SDLC phases.

6.    In order to audit technical work products (such as database design or physical design), auditor may opt to include a technical expert to seek his/her opinion on the technical aspects of SDLC.

7.    However, auditor will have to give control objectives, directives and in general validate the opinion expressed by technical experts.

Some of the control considerations for an auditor are:

      Documented policy and procedures;

      Established Project team with all infrastructure and facilities ;

      Developers/ IT managers are trained on the procedures ;

      Appropriate approvals are being taken at identified mile-stones;

      Development is carried over as per standards, functional specifications;

      Separate test environment for development/ test/ production / test plans;

      Design norms and naming conventions are as per standards and are adhered to;

      Business owners testing and approval before system going live;

      Version control on programs;

      Source Code is properly secured;

      Adequate audit trails are provided in system; and

      Appropriateness of methodologies selected.

8.    Further, Post-Implementation Review (PIR) is performed to determine whether the system adequately meets earlier identified business requirements and needs (in feasibility studies or Requirements Specifications).

9.    Auditors should be able to determine if the expected benefits of the new system were realized and whether users are satisfied with the new system.

10. In PIR, auditors need to review which of the SDLC phases have not met desired objectives and whether any corrective actions were taken.

11. If there are differences between expectations and actual results, auditors need to determine the reasons for the same. E.g. it could be due to incomplete user requirements. Such reasons can help auditors to evaluate the current situation and offer guidelines for future projects.

Master Checklist  ( Amendment)

The process objectives are:

·         To ensure an appropriate acquisition and / or development of information systems  including software, and

·         To maintain the information systems in an appropriate manner.

Amendments in ISCA

Hey friends,

Hope u are doing well !!!!

Following are the amendments in ISCA and are applicable for Nov - 2012 exam :

Chapter - 5 : Risk Management Process :

Risk Management Process:  (Latest Amendment)

The process of Information Risk Management typically involves the following steps:

Step 1: Identification of Information Assets

Step 2: Valuation of Information Assets

Step 3: Identifying the potential threats & Vulnerabilities

Step 4: Information Risk Assessment

Step 5: Developing Strategies for Information Risk Management

The detail of each step is given as follows:

Step 1: Identification of Information Assets

ü  Identify the information assets supporting critical business operations that need to be protected.

The assets could fall under different groups which are:

a)    Conceptual / Intangible Assets :

1.    Data and Information:

ü  Business and related information contained in various storage devices such as hard disks or in transit may be subject to unauthorized disclosure, copying, theft, corruption or damage.

2.    Software:

ü  Application software (application packages for accounting, payroll, sales etc.) and system software (operating system, utility programs, compiler, communication software, DBMS etc.):

ü  Such programs may be susceptible to intentional or unintentional unauthorized modification by persons internal or external to the organization or by faulty technology processes.

b)   Physical / Tangible Assets :

Ø  People (e.g. skilled users, analysts, programmers etc.)

Ø  Hardware (e.g. mainframes, minicomputers, microcomputers, storage media, printers)

Ø  Networking devices (e.g. communication lines, concentrators, hubs and switches etc.)

Ø  Facilities: The computing and communication equipments such as servers could require special environment such as air-conditioned, dust free, humidity controlled facilities.

Ø  Documentation (e.g. printed forms, manuals, system and database documentation, IS policies & procedures)

Step 2: Valuation of Information Assets

ü  The information classification process focuses on business risk and data valuation.

ü  Information systems resources should be classified or categorized according to their sensitivity. In other words, information classification should be done based based upon their critical value it possess.

Ø  Critical info :  Startegic plans , formulas , trade secrets etc.

Ø  Less critical info : list of customers, details of employees’ salaries, etc

ü  With the loss of information relating to trade secrets, formulas , new product information organisation’s credibility might be questioned.

ü  Thus in order to ensure cost-effective controls, it is beneficial to classify the entire organizational information. Also it helps in avoiding the cost of over-protecting and under protecting the information.

The assets so identified and grouped may be categorized into different classes, which are:

a)    Top secret:  

·         This indicates the highest classification wherein the compromise of the confidentiality, integrity and availability can endanger the existence of the organization.   

·         Access to such information may be restricted to either a few named individuals in the organization or to a set of identified individuals.

b)    Secret:

·         Information in this category is strategic to the survival of the organization.

·         Unauthorized disclosure could cause severe damage to the organization and stakeholders.

c)    Confidential:

·         Information in this category also needs high levels of protection but unauthorized disclosure may cause significant loss or damage.

·         Such information is highly sensitive and should be well protected.

d)    Sensitive:

·         Such information requires higher classification as compared to unclassified information.

·         Disclosure may cause serious impact.

e)    Unclassified:

·         Information that does not fall in any of the above categories finds place here.

·         This also implies that the nature of the information is such that its unauthorized disclosure would not cause any adverse impact on the organization.

·         Such information may also be made freely available to the public.

Another type of classification, popular in commercial organizations, can be:

Public, Sensitive, Private and Confidential.

Step 3: Identifying the potential threats & Vulnerabilities:

·         Threat can be defined as an event that contributes to the interruption or destruction of any service, product or process.

·         Common classes of threats are:

ü  Errors , Malicious damage/attack

ü  Fraud , Theft , Equipment/software failure

·         Threats occur because of vulnerabilities associated with use of information resources.

·         Vulnerability is the weakness in the system safeguards that exposes the system to threats.

·         It may be weakness in a

ü  information system,

ü  cryptographic system (security systems),

ü  Hardware Design

ü  Internal control

·         Examples of vulnerabilities are:

ü  Lack of user knowledge , Lack of security functionality

ü  Poor choice of passwords , Untested technology

ü  Transmission over unprotected communication medium

Threats Computer systems could affect the confidentiality, integrity or availability of system information or resources.

a)    Confidentiality :

Ø  It involves the protection of the organization’s sensitive information from disclosure to unauthorized persons and processes.

b)    Integrity :

Ø  It involves protection against any intentional / accidental unauthorized modification, which may result in serious consequences to the business.

Ø  e.g: Computer virus may cause corruption of data/program thereby causing loss of transactions or state of integrity of such transactions.

c)    Availability :

Ø  It emphasis on whether the information systems and processes critical for conduct of business are available to authorized users as and when required.

Ø  E.g. Denial-of-service attack.

Step 4: Information Risk Assessment :

Ø  Once the assets and corresponding potential threats have been identified, the systems are reviewed for weaknesses that can be exploited and the likelihood of those being exploited.

This can be done by :

a)    Vulnerability Assessment :

ü  Vulnerability is the weakness in the system safeguards that exposes the system to threats.

ü  Sometimes the threat viewed in isolation may be misleading unless the vulnerabilities are taken into consideration. In most cases the threats attempt to exploit the vulnerabilities to cause loss or harm to the assets.

ü  For example, a hacker would look for loopholes in the architecture of the firewall to compromise the controls and gain unauthorized access to the networks.

b)    Probability or Likelihood Assessment :

ü  Likelihood is the chance of a threat happening.

ü  A likelihood assessment considers the presence, tenacity and strength of threats, as well as, the effectiveness of safeguards.

ü  In general, the greater the likelihood of a threat occurring, the greater is the risk.

ü  To some extent, the nature and value of information assets affect the likelihood of occurrence of a threat. If the asset is of high value, e.g. proprietary software packages, it is a prime target for piracy attempts.

ü  Periodically, the likelihood of occurrence of a threat needs to be reassessed due to changes occurring in the structure, direction, and environment of an organization.

c)    Impact Analysis :

ü  The threat that is successful in causing harm or loss to an asset results in an impact.

ü  Impact may be either in monetary or non – monetary terms. e.g. loss of profit & loss of goodwill .

Step 5: Developing Strategies for Information Risk Management

·         Once risks have been identified and assessed, appropriate corrections shall be made to the system, if required.

·         Immediate action may not be taken to correct some identified vulnerabilities but the process will at least analyse these vulnerabilities, document and recognize them for risk management decisions.

The strategies to manage the risk fall into one or more of these four major categories:

a)    Risk Avoidance:

ü  It means not doing an activity that involves risk.

ü  It involves losing out on the potential gain that accepting the risk might have provided.  

ü  E.g. not using Internet / public network on a system connected to organisation’s internal network, instead using a stand-alone PC for Internet usage.

b)    Risk Mitigation / Reduction:

ü  It involves implementing controls to protect IT infrastructure and to reduce the severity of the loss or the likelihood of the loss from occurring.

ü  E.g. Using Anti –virus s/w for Virus attack.

c)    Risk Transfer:

ü  It involves causing another party to accept the risk i.e. sharing risk with partners or insurance coverage.

d)    Risk Retention / Acceptance:  ( Do nothing stratergy – Residual Risk)

ü  It means formally acknowledging that the risk exists and monitoring it. These risks are called residual risks.

ü  Risk management aims to identify, select and implement the controls that are necessary to reduce residual exposures to acceptable levels.

o   The goals and mission of an organization should be considered in selecting any of these risk management strategies.

o   It may not be practical to address all identified risks, hence prioritization is required.

o   In prioritization process the risks with the greatest loss and the greatest probability of occurrence are handled first, and risks with lower probability of occurrence and lower loss are handled later. Practically this process can be difficult to be handeled. 

Understanding the Relationships Between IS Risks and Controls

      Risks that threaten the IS cannot be altogether eliminated but, through appropriate decisions and actions can be mitigated. ( Link : Residual risk )

      Any threat to the system or its components could result in a loss to the company as a consequence of exploitation of the vulnerabilities.

      A control is a check or restraint on a system which is designed to enhance its security.

      Controls can act to reduce :

o    threat

o   vulnerability to a threat

o   detect &  recover from an impact of a threat

      The objective of IS controls is to :

ü  prevent the threats from exploiting the vulnerabilities of the assets or the safeguards.

ü  Timely detect and trigger corrective action ( if threats can’t be prevented)

      In the event of failure of a control, threats could cause harm to the assets resulting in an actual impact.

      IS Auditor should be able to  evaluate whether available controls are adequate and appropriate to mitigate the IS risks.

      In the case of deficiency , auditor should report such weaknesses to the auditee management along with appropriate recommendations.

      Hence it is important for the IS auditor to understand the relationship between risks and controls.

The following rules apply in determining the use of new controls:

o   If control would reduce risk more than needed, then see whether a less expensive alternative exists.

o   If control does not reduce risk sufficiently, then look for more controls or a different control.

o   If control would cost more than the risk reduction provided, then find something else.

o   If control provides enough risk reduction and is cost-effective also, then use it