IT Controls Part I: Sarbanes-Oxley & IT Governance

IT Controls Part I: Sarbanes-Oxley & IT Governance

Objectives Understand the key features of Sections 302 and 404 of the Sarbanes-Oxley Act. Understand management and auditor responsibilities under Sections 302 and 404. Understand the risks of incompatible functions and how to structure the IT function. Be familiar with the controls and precautions required to ensure the security of an organization’s computer facilities. Understand the key elements of a disaster recovery plan. Be familiar with the benefits, risks and audit issues related to IT Outsourcing.

Sarbanes-Oxley Act Created company accounting oversight board
The 2002 Sarbanes-Oxley (SOX) Act established new corporate governance rules Created company accounting oversight board Increased accountability for company officers and board of directors Increased white collar crime penalties Prohibits a company’s external audit firms from designing and implementing financial information systems

SOX Section 302 Section 302—in quarterly and annual financial statements, management must: certify the internal controls (IC) over financial reporting state responsibility for IC design provide reasonable assurance as to the reliability of the financial reporting process disclose any recent material changes in IC

SOX Section 404 Section 404—in the annual report on IC effectiveness, management must: state responsibility for establishing and maintaining adequate financial reporting IC assess IC effectiveness reference the external auditors’ attestation report on management’s IC assessment provide explicit conclusions on the effectiveness of financial reporting IC identify the framework management used to conduct their IC assessment, e.g., COBIT

IT Controls & Financial Reporting
Modern financial reporting is driven by information technology (IT) IT initiates, authorizes, records, and reports the effects of financial transactions. Financial reporting IC are inextricably integrated to IT.

COSO identifies two groups of IT controls: application controls – apply to specific applications and programs, and ensure data validity, completeness and accuracy general controls – apply to all systems and address IT governance and infrastructure, security of operating systems and databases, and application and program acquisition and development

Significant Financial Accounts Sales CGS Inventory AP Cash Order Entry Application Controls Purchases Application Controls Cash Disbursements Application Controls Related Application Controls Controls for Review Systems Development and Program Change Control Supporting General Controls Database Access Controls Operating System Controls

SOX Audit Implications
Pre-SOX, audits did not require IC tests. Only required to be familiar with client’s IC Audit consisted primarily of substantive tests SOX – radically expanded scope of audit Issue new audit opinion on management’s IC assessment Required to test IC affecting financial information, especially IC to prevent fraud Collect documentation of management’s IC tests and interview management on IC changes

Types of Audit Tests Tests of controls – tests to determine if appropriate IC are in place and functioning effectively Substantive testing – detailed examination of account balances and transactions

Organizational Structure IC
Audit objective – verify that individuals in incompatible areas are segregated to minimize risk while promoting operational efficiency IC, especially segregation of duties, affected by which of two organizational structures applies: Centralized model Distributed model 25 25

Organizational Chart of a Centralized Information Technology Function
Figure 15-3

Distributed Organization with Corporate Information Technology Function
Figure 15-5

Segregation of Duties Transaction authorization is separate from transaction processing. Asset custody is separate from record-keeping responsibilities. The tasks needed to process the transactions are subdivided so that fraud requires collusion. 3

Segregation of Duties Objectives
Nested Control Objectives for Transactions TRANSACTION Control Objective 1 Objective 2 Objective 3 Authorization Processing Authorization Custody Recording Subsidiary Ledgers General Ledger Journals Figure 3-4 45

Centralized IT Structure
Critical to segregate: systems development from computer operations database administrator (DBA) from other computer service functions DBA’s authorizing and systems development’s processing DBA authorizes access maintenance from new systems development data library from operations 26

Distributed IT Structure
Despite its many advantages, important IC implications are present: incompatible software among the various work centers data redundancy may result consolidation of incompatible tasks difficulty hiring qualified professionals lack of standards 28 28

Organizational Structure IC
A corporate IT function alleviates potential problems associated with distributed IT organizations by providing: central testing of commercial hardware and software a user services staff a standard-setting body reviewing technical credentials of prospective systems professionals 29

Audit Procedures Review the corporate policy on computer security Verify that the security policy is communicated to employees Review documentation to determine if individuals or groups are performing incompatible functions Review systems documentation and maintenance records Verify that maintenance programmers are not also design programmers

Audit Procedures Observe if segregation policies are followed in practice. E.g., check operations room access logs to determine if programmers enter for reasons other than system failures Review user rights and privileges Verify that programmers have access privileges consistent with their job descriptions

Computer Center IC Audit objectives:
physical security IC protects the computer center from physical exposures insurance coverage compensates the organization for damage to the computer center operator documentation addresses routine operations as well as system failures 18

Computer Center IC Considerations:
man-made threats and natural hazards underground utility and communications lines air conditioning and air filtration systems access limited to operators and computer center workers; others required to sign in and out fire suppression systems installed fault tolerance redundant disks and other system components backup power supplies 36

Audit Procedures Review insurance coverage on hardware, software, and physical facility Review operator documentation, run manuals, for completeness and accuracy Verify that operational details of a system’s internal logic are not in the operator’s documentation

Disaster Recovery Planning
Disaster recovery plans (DRP) identify: actions before, during, and after the disaster disaster recovery team priorities for restoring critical applications Audit objective – verify that DRP is adequate and feasible for dealing with disasters 37

Disaster Recovery Planning
Major IC concerns: second-site backups critical applications and databases including supplies and documentation back-up and off-site storage procedures disaster recovery team testing the DRP regularly 37

Second-Site Backups Empty shell - involves two or more user organizations that buy or lease a building and remodel it into a computer site, but without computer equipment Recovery operations center - a completely equipped site; very costly and typically shared among many companies Internally provided backup - companies with multiple data processing centers may create internal excess capacity 38

DRP Audit Procedures Evaluate adequacy of second-site backup arrangements Review list of critical applications for completeness and currency Verify that procedures are in place for storing off-site copies of applications and data Check currency back-ups and copies

DRP Audit Procedures Verify that documentation, supplies, etc., are stored off-site Verify that the disaster recovery team knows its responsibilities Check frequency of testing the DRP

Benefits of IT Outsourcing
Improved core business processes Improved IT performance Reduced IT costs

Risks of IT Outsourcing
Failure to perform Vendor exploitation Costs exceed benefits Reduced security Loss of strategic advantage

Audit Implications of IT Outsourcing
Management retains SOX responsibilities SAS No. 70 report or audit of vendor will be required

Audit Background Material
From Appendix

Attestation versus Assurance
practitioner is engaged to issue a written communication that expresses a conclusion about the reliability of a written assertion that is the responsibility of another party. Assurance: professional services that are designed to improve the quality of information, both financial and non-financial, used by decision-makers includes, but is not limited to attestation 3

Attest and Assurance Services
Figure 15-8 3

What is an External Financial Audit?
An independent attestation by a professional (CPA) regarding the faithful representation of the financial statements Three phases of a financial audit: familiarization with client firm evaluation and testing of internal controls assessment of reliability of financial data 2

Generally Accepted Auditing Standards (GAAS)

Auditing Management’s Assertions

External versus Internal Auditing
External auditors – represent the interests of third party stakeholders Internal auditors – serve an independent appraisal function within the organization Often perform tasks which can reduce external audit fees and help to achieve audit efficiency 3

What is an IT Audit? IT audits:
Since most information systems employ IT, the IT audit is a critical component of all external and internal audits. IT audits: focus on the computer-based aspects of an organization’s information system assess the proper implementation, operation, and control of computer resources 3

Elements of an IT Audit Systematic procedures are used
Evidence is obtained tests of internal controls substantive tests Determination of materiality for weaknesses found Prepare audit report & audit opinion 4

Phases of an IT Audit Figure 15-9 5

Audit Risk is... the probability the auditor will issue an unqualified (clean) opinion when in fact the financial statements are materially misstated. 7

Three Components of Audit Risk
Inherent risk – associated with the unique characteristics of the business or industry of the client Control risk – the likelihood that the control structure is flawed because controls are either absent or inadequate to prevent or detect errors in the accounts Detection risk – the risk that errors not detected or prevented by the control structure will also not be detected by the auditor 9

Computer Fraud Schemes
Theft, misuse, or misappropriation of assets by altering computer-readable records and files Theft, misuse, or misappropriation of assets by altering logic of computer software Theft or illegal use of computer-readable information Theft, corruption, illegal copying or intentional destruction of software Theft, misuse, or misappropriation of computer hardware 22

Using the general IS model,
explain how fraud can occur at the different stages of information processing? 13

Data Collection Fraud This aspect of the system is the most vulnerable because it is relatively easy to change data as it is being entered into the system. Also, the GIGO (garbage in, garbage out) principle reminds us that if the input data is inaccurate, processing will result in inaccurate output. 23

Data Processing Fraud Program Frauds
altering programs to allow illegal access to and/or manipulation of data files destroying programs with a virus Operations Frauds misuse of company computer resources, such as using the computer for personal business 24

Database Management Fraud
Altering, deleting, corrupting, destroying, or stealing an organization’s data Oftentimes conducted by disgruntled or ex-employee 25

Information Generation Fraud
Stealing, misdirecting, or misusing computer output Scavenging searching through the trash cans on the computer center for discarded output (the output should be shredded, but frequently is not) 26

IT Controls Part II: Security and Access

Objectives Be able to identify the principal threats to the operating system and the control techniques used to minimize the possibility of actual exposures. Be familiar with the principal risks associated with electronic commerce conducted over intranets and the Internet and understand the control techniques used to reduce these risks. Be familiar with the risks to database integrity and the controls used to mitigate them. Recognize the unique exposures that arise in connection with electronic data interchange (EDI) and understand how these exposures can be reduced.

Operating Systems Perform three main tasks:
translates high-level languages into the machine-level language allocates computer resources to user applications manages the tasks of job scheduling and multiprogramming 10

Requirements for Effective Operating Systems Performance
Protect against tampering by users Prevent users from tampering with the programs of other users Safeguard users’ applications from accidental corruption Safeguard its own programs from accidental corruption Protect itself from power failures and other disasters 11 11

Operating Systems Security
Log-On Procedure first line of defense – user IDs and passwords Access Token contains key information about the user Access Control List defines access privileges of users Discretionary Access Control allows user to grant access to another user 13

Operating Systems Controls
Access Privileges Audit objectives: verify that access privileges are consistent with separation of incompatible functions and organization policies Audit procedures: review or verify… policies for separating incompatible functions a sample of user privileges, especially access to data and programs security clearance checks of privileged employees formal acknowledgements to maintain confidentiality of data users’ log-on times 18

Operating Systems S Controls
Password Control Audit objectives: ensure adequacy and effectiveness of password policies for controlling access to the operating system Audit procedures: review or verify… passwords required for all users password instructions for new users passwords changed regularly password file for weak passwords encryption of password file password standards account lockout policies 18

Operating Systems Controls
Malicious & Destructive Programs Audit objectives: verify effectiveness of procedures to protect against programs such as viruses, worms, back doors, logic bombs, and Trojan horses Audit procedures: review or verify… training of operations personnel concerning destructive programs testing of new software prior to being implemented currency of antiviral software and frequency of upgrades 18

Operating System Controls
Audit Trail Controls Audit objectives: used to (1) detect unauthorized access, (2) facilitate event reconstruction, and/or (3) promote accountability Audit procedures: review or verify… how long audit trails have been in place archived log files for key indicators monitoring and reporting of security violations 18

Database Management Controls
Two crucial database control issues: Access controls Audit objectives: (1) those authorized to use databases are limited to data needed to perform their duties and (2) unauthorized individuals are denied access to data Backup controls Audit objectives: backup controls can adequately recover lost, destroyed, or corrupted data 21 21

Access Controls User views - based on sub-schemas
Database authorization table - allows greater authority to be specified User-defined procedures - used to create a personal security program or routine Data encryption - encoding algorithms Biometric devices - fingerprints, retina prints, or signature characteristics 22 22

Database Authorization Table
Figure 16-2

Access Controls Audit procedures: verify…
responsibility for authority tables & subschemas granting appropriate access authority use or feasibility of biometric controls use of encryption 21 21

Subschema Restricting Access
Figure 16-1

Backup Controls Database backup – automatic periodic copy of data
Transaction log – list of transactions that provides an audit trail Checkpoint features – suspends data during system reconciliation Recovery module – restarts the system after a failure 24

Backup Controls Audit procedures: verify…
that production databases are copied at regular intervals backup copies of the database are stored off site to support disaster recovery 21 21

Internet and Intranet Risks
The communications component is a unique aspect of computer networks: different than processing (applications) or data storage (databases) Network topologies – configurations of: communications lines (twisted-pair wires, coaxial cable, microwaves, fiber optics) hardware components (modems, multiplexers, servers, front-end processors) software (protocols, network control systems) 2

Sources of Internet & Intranet Risks
Internal and external subversive activities Audit objectives: prevent and detect illegal internal and Internet network access render useless any data captured by a perpetrator preserve the integrity and physical security of data connected to the network Equipment failure Audit objective: the integrity of the electronic commerce transactions by determining that controls are in place to detect and correct message loss due to equipment failure 2

Risks from Subversive Threats
Include: unauthorized interception of a message gaining unauthorized access to an organization’s network a denial-of-service attack from a remote location 2

IC for Subversive Threats
Firewalls provide security by channeling all network connections through a control gateway. Network level firewalls Low cost and low security access control Do not explicitly authenticate outside users Filter junk or improperly routed messages Experienced hackers can easily penetrate the system Application level firewalls Customizable network security, but expensive Sophisticated functions such as logging or user authentication 3

Dual-Homed Firewall Figure 16-4

Denial-of-service (DOS) attacks Security software searches for connections which have been half-open for a period of time. Encryption Computer program transforms a clear message into a coded (cipher) text form using an algorithm. 4

SYN Flood DOS Attack Sender Receiver Step 1: SYN messages
Step 2: SYN/ACK Step 3: ACK packet code In a DOS Attack, the sender sends hundreds of messages, receives the SYN/ACK packet, but does not response with an ACK packet. This leaves the receiver with clogged transmission ports, and legitimate messages cannot be received. 6

Controlling DOS Attacks
Controlling for three common forms of DOS attacks: Smurf attacks—organizations can program firewalls to ignore an attacking site, once identified SYN flood attacks—two tactics to defeat this DOS attack Get Internet hosts to use firewalls that block invalid IP addresses Use security software that scan for half-open connections DDos attacks–many organizations use Intrusion Prevention Systems (IPS) that employ deep packet inspection (DPI) IPS works with a firewall filter that removes malicious packets from the flow before they can affect servers and networks DPI searches for protocol non-compliance and employs predefined criteria to decide if a packet can proceed to its destination (See chapter 12 for more on DOS attacks) 4

Encryption The conversion of data into a secret code for storage and transmission The sender uses an encryption algorithm to convert the original cleartext message into a coded ciphertext. The receiver decodes / decrypts the ciphertext back into cleartext. Encryption algorithms use keys Typically 56 to 128 bits in length The more bits in the key the stronger the encryption method. Two general approaches to encryption are private key and public key encryption.

Private Key Encryption
Advance encryption standard (AES) A 128 bit encryption technique A US government standard for private key encryption Uses a single key known to both sender and receiver Triple Data Encryption Standard (DES ) Considerable improvement over single encryption techniques Two forms of triple-DES encryption are EEE3 and EDE3 EEE3 uses three different keys to encrypt the message three times. EDE3—one key encrypts, but two keys are required for decoding All private key techniques have a common problem The more individuals who need to know the key, the greater the probability of it falling into the wrong hands. The solution to this problem is public key encryption.

The Advanced Encryption Standard Technique
Figure 16-5

EEE3 and EDE3 Encryption Figure 16-6

Digital signature – electronic authentication technique to ensure that… transmitted message originated with the authorized sender message was not tampered with after the signature was applied Digital certificate – like an electronic identification card used with a public key encryption system Verifies the authenticity of the message sender

Digital Signature Figure 16-7

Message sequence numbering – sequence number used to detect missing messages Message transaction log – listing of all incoming and outgoing messages to detect the efforts of hackers Request-response technique – random control messages are sent from the sender to ensure messages are received Call-back devices – receiver calls the sender back at a pre-authorized phone number before transmission is completed 9

Auditing Procedures for Subversive Threats
Review firewall effectiveness in terms of flexibility, proxy services, filtering, segregation of systems, audit tools, and probing for weaknesses. Review data encryption security procedures Verify encryption by testing Review message transaction logs Test procedures for preventing unauthorized calls

IC for Equipment Failure
Line errors are data errors from communications noise. Two techniques to detect and correct such data errors are: echo check - the receiver returns the message to the sender parity checks - an extra bit is added onto each byte of data similar to check digits 11

Vertical and Horizontal Parity using Odd Parity
Figure 16-8

Auditing Procedures for Equipment Failure
Using a sample of messages from the transaction log: examine them for garbled contents caused by line noise verify that all corrupted messages were successfully retransmitted

Electronic Data Interchange
Electronic data interchange (EDI) uses computer-to-computer communications technologies to automate B2B purchases. Audit objectives: Transactions are authorized, validated, and in compliance with the trading partner agreement. No unauthorized organizations can gain access to database Authorized trading partners have access only to approved data. Adequate controls are in place to ensure a complete audit trail. 9

EDI Risks Authorization automated and absence of human intervention
Access need to access EDI partner’s files Audit trail paperless and transparent (automatic) transactions 9

EDI Controls Authorization
use of passwords and value added networks (VAN) to ensure valid partner Access software to specify what can be accessed and at what level Audit trail control log records the transaction’s flow through each phase of the transaction processing 9

EDI System Figure 16-9

EDI System using Transaction Control Log for Audit Trail
Figure 16-10

Auditing Procedures for EDI
Tests of Authorization and Validation Controls Review procedures for verifying trading partner identification codes Review agreements with VAN Review trading partner files Tests of Access Controls Verify limited access to vendor and customer files Verify limited access of vendors to database Test EDI controls by simulation Tests of Audit Trail Controls Verify existence of transaction logs Review a sample of transactions

IT Controls Part III: Systems Development, Program Changes, and Application Controls

Objectives for Chapter 17
Be familiar with the controls and audit tests relevant to the systems development process. Understand the risks and controls associated with program change procedures and the role of the source program library. Understand the auditing techniques (CAATTs) used to verify the effective functioning of application controls. Understand the auditing techniques used to perform substantive tests in an IT environment.

Systems Development Activities
Authorizing development of new systems Addressing and documenting user needs Technical design phases Participation of internal auditors Testing program modules before implementing Testing individual modules by a team of users, internal audit staff, and systems professionals 30 30

System Development Life Cycle
Figure 14-1

Systems Development Auditing objectives: ensure that...
SDLC activities are applied consistently and in accordance with management’s policies the system as originally implemented was free from material errors and fraud the system was judged to be necessary and justified at various checkpoints throughout the SDLC system documentation is sufficiently accurate and complete to facilitate audit and maintenance activities 14

Systems Development IC
New systems must be authorized. Feasibility studies were conducted. User needs were analyzed and addressed. Cost-benefit analysis was done. Proper documentation was completed. All program modules must be thoroughly tested before they are implemented. Checklist of problems was kept. 30 30

System Maintenance IC Last, longest and most costly phase of SDLC
Up to 80-90% of entire cost of a system All maintenance actions should require Technical specifications Testing Documentation updates Formal authorizations for any changes 31 31

Program Change Auditing objectives: detect unauthorized program maintenance and determine that... maintenance procedures protect applications from unauthorized changes applications are free from material errors program libraries are protected from unauthorized access 16

Source Program Library
Source program library (SPL) library of applications and software place where programs are developed and modified once compiled into machine language, no longer vulnerable 31 31

Uncontrolled Access to the SPL
Figure 17-2 32

Controlled SPL Environments
SPL Management Systems (SPLMS) protect the SPL by controlling the following functions: storing programs on the SPL retrieving programs for maintenance purposes deleting obsolete programs from the library documenting program changes to provide an audit trail of the changes 33

Source Program Library under the Control of SPL Management Software
Figure 17-3 34

SPL Control Features Password control Separation of test libraries
Audit trails Reports that enhance management control and the audit function Assigns program version numbers automatically Controlled access to maintenance commands 35

Program Change Auditing procedures: verify that programs were properly maintained, including changes Specifically, verify… identification and correction of unauthorized program changes identification and correction of application errors control of access to systems libraries 16

Application Controls Narrowly focused exposures within a specific system, for example: accounts payable cash disbursements fixed asset accounting payroll sales order processing cash receipts general ledger 9 9

Application Controls Risks within specific applications
Can affect manual procedures (e.g., entering data) or embedded (automated) procedures Convenient to look at in terms of: input stage processing stage output stage PROCESSING INPUT OUTPUT 21 21

Application Input Controls
Goal of input controls - valid, accurate, and complete input data Two common causes of input errors: transcription errors – wrong character or value transposition errors – ‘right’ character or value, but in wrong place 21 21

Check digits – data code is added to produce a control digit especially useful for transcription and transposition errors Missing data checks – control for blanks or incorrect justifications Numeric-alphabetic checks – verify that characters are in correct form 22 22

Limit checks – identify values beyond pre-set limits Range checks – identify values outside upper and lower bounds Reasonableness checks – compare one field to another to see if relationship is appropriate Validity checks – compares values to known or standard values 23 23

Application Processing Controls
Programmed processes that transform input data into information for output Three categories: Batch controls Run-to-run controls Audit trail controls 30

Batch controls - reconcile system output with the input originally entered into the system Based on different types of batch totals: total number of records total dollar value hash totals – sum of non-financial numbers 22 22

Run-to-run controls - use batch figures to monitor the batch as it moves from one programmed procedure (run) to another Audit trail controls - numerous logs used so that every transaction can be traced through each stage of processing from its economic source to its presentation in financial statements 30

Transaction Log to Preserve the Audit Trail
Figure 17-7

Application Output Controls
Goal of output controls is to ensure that system output is not lost, misdirected, or corrupted, and that privacy is not violated. In the following flowchart, there are exposures at every stage. 33

Stages in the Output Process
Figure 17-8

Application Controls Output
Output spooling – creates a file during the printing process that may be inappropriately accessed Printing – create two risks: production of unauthorized copies of output employee browsing of sensitive data 33

Waste – can be stolen if not properly disposed of, e.g., shredding Report distribution – for sensitive reports, the following are available: use of secure mailboxes require the user to sign for reports in person deliver the reports to the user 33

End user controls – end users need to inspect sensitive reports for accuracy shred after used Controlling digital output – digital output message can be intercepted, disrupted, destroyed, or corrupted as it passes along communications links 35

Testing Application Controls
Techniques for auditing applications fall into two classes: testing application controls – two general approaches: black box – around the computer white box – through the computer examining transaction details and account balances—substantive testing 3

Auditing Around the Computer - The Black Box Approach
Figure 17-9

Auditing through the Computer: The ITF Technique
Figure 17-14

Black Box Approach – focuses on input procedures and output results To Gain need understanding… analyze flowcharts review documentation conduct interviews 25

White Box Approach - focuses on understanding the internal logic of processes between input and output Common tests Authenticity tests Accuracy tests Completeness tests Redundancy tests Access tests Audit trail tests Rounding error tests 25

White Box Testing Techniques
Test data method: testing for logic or control problems - good for new systems or systems which have undergone recent maintenance base case system evaluation (BCSE) - using a comprehensive set of test transactions tracing - performs an electronic walkthrough of the application’s internal logic Test data methods are not fool-proof a snapshot - one point in time examination high-cost of developing adequate test data 27

White Box Testing Techniques
Integrated test facility (ITF): an automated, on-going technique that enables the auditor to test an application’s logic and controls during its normal operation Parallel simulation: auditor writes simulation programs and runs actual transactions of the client through the system

The Parallel Simulation Technique
Figure 17-15

Substantive Testing Techniques to substantiate account balances. For example: search for unrecorded liabilities confirm accounts receivable to ensure they are not overstated Requires first extracting data from the system. Two technologies commonly used to select, access, and organize data are: embedded audit module generalized audit software 33

Embedded Audit Module An ongoing module which filters out non- material transactions The chosen, material transactions are used for sampling in substantive tests Requires additional computing resources by the client Hard to maintain in systems with high maintenance 34

Embedded Audit Module Technique
Figure 17-16

Generalized Audit Software
Very popular & widely used Can access data files & perform operations on them: screen data statistical sampling methods foot & balance format reports compare files and fields recalculate data fields 36

Complex File Structure
Using GAS to Access Complex File Structure Figure 17-18

IT Controls Part I: Sarbanes-Oxley & IT Governance

Similar presentations

Presentation on theme: "IT Controls Part I: Sarbanes-Oxley & IT Governance"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

IT Controls Part I: Sarbanes-Oxley & IT Governance

Similar presentations

Presentation on theme: "IT Controls Part I: Sarbanes-Oxley & IT Governance"— Presentation transcript:

Similar presentations

About project

Feedback