e-pramaan standards & specifications 19 september 2015 © centre for development of advanced...

e-Pramaan Standards & Specificationse-Pramaan Standards & Specifications

April 19, 2023© Centre for Development of Advanced Computing 1

ContentsContents

e-Pramaan – Introduction

User Provisioning and De-provisioning

User Provisioning

User Profile Up-gradation

User Suspension & De-provisioning

Service Provider Enlistment

Credential Handling in e-Pramaan

Password

PIN

One Time Password (OTP)

e-Pramaan – Introduction

User Provisioning and De-provisioning

User Provisioning

User Profile Up-gradation

User Suspension & De-provisioning

Service Provider Enlistment

Credential Handling in e-Pramaan

Password

PIN

One Time Password (OTP)April 19, 2023 © Centre for Development of Advanced Computing 2

ContentsContents

Digital Certificates

e-Pramaan CA

Licensed Indian CA

Digital Certificates Revocation

Biometrics

Identity Attributes in e-Pramaan

Session Policy Management

Communication and Security

Service Agreements

Audit Trail Management

Digital Certificates

e-Pramaan CA

Licensed Indian CA

Digital Certificates Revocation

Biometrics

Identity Attributes in e-Pramaan

Session Policy Management

Communication and Security

Service Agreements

Audit Trail Management

April 19, 2023 © Centre for Development of Advanced Computing 3

e-Pramaan – Introductione-Pramaan – Introduction

e-Pramaan is an authentication service, based on established authentication standards, to be developed for government departments.

It provides a convenient and secured way for the users to access government services via internet/mobile.

It provides Uniform authentication mechanism for all e-Governance Services.

It provides Single Sign On (SSO) for e-Governance Services integrated to e-Pramaan.

The departments, MUST have to first integrate with e-Pramaan.

SHALL provide ‘Login using e-Pramaan’ link on their home page.

User MUST be redirected to e-Pramaan registration / login.

e-Pramaan is an authentication service, based on established authentication standards, to be developed for government departments.

It provides a convenient and secured way for the users to access government services via internet/mobile.

It provides Uniform authentication mechanism for all e-Governance Services.

It provides Single Sign On (SSO) for e-Governance Services integrated to e-Pramaan.

The departments, MUST have to first integrate with e-Pramaan.

SHALL provide ‘Login using e-Pramaan’ link on their home page.

User MUST be redirected to e-Pramaan registration / login.


e-Pramaan – Introductione-Pramaan – Introduction

e-Pramaan provides 4 levels of authentication based on the sensitivity requirement of e-Governance services. Level 1: username and password.

Level 2: One Time Password (OTP) along with the user’s Level 1 credentials.

Level 3: Digital Certificates and level-1 credentials.

Level 4: biometrics along with Level-1 credentials.

e-Pramaan provides 4 levels of authentication based on the sensitivity requirement of e-Governance services. Level 1: username and password.

Level 2: One Time Password (OTP) along with the user’s Level 1 credentials.

Level 3: Digital Certificates and level-1 credentials.

Level 4: biometrics along with Level-1 credentials.


User Provisioning on e-PramaanUser Provisioning on e-Pramaan

Multiple Scenarios of User Registration

Scenario 1 : Users not Registered to e-Pramaan and not Enrolled to Service Provider (SP) -

User may self-register on e-Pramaan Using Aadhaar Number as the Username

Using Username of Her Choice (without Aadhaar Credentials)

Scenario 2: Users not Registered to e-Pramaan but Enrolled to SP – During Sign-in on SP, the SP shall redirect user to e-Pramaan for registration

Registration Process in Scenario 1 is followed at e-Pramaan.

Scenario 3: Users Registered to e-Pramaan, but not Enrolled to SP –e-Pramaan redirects user to SP for enrolment along with the registration data for pre-filling the SP registration

form.

Multiple Scenarios of User Registration

Scenario 1 : Users not Registered to e-Pramaan and not Enrolled to Service Provider (SP) -

User may self-register on e-Pramaan Using Aadhaar Number as the Username

Using Username of Her Choice (without Aadhaar Credentials)

Scenario 2: Users not Registered to e-Pramaan but Enrolled to SP – During Sign-in on SP, the SP shall redirect user to e-Pramaan for registration

Registration Process in Scenario 1 is followed at e-Pramaan.

Scenario 3: Users Registered to e-Pramaan, but not Enrolled to SP –e-Pramaan redirects user to SP for enrolment along with the registration data for pre-filling the SP registration

form.


User Provisioning on e-PramaanUser Provisioning on e-Pramaan

Users Registered to e-Pramaan and Enrolled to SP –

e-Pramaan sends one-time user- verification request to the SP. Once verified, SP will send the UserID and SP-ID to e-Pramaan for correlation.

Correlating is linking the username on the SP and e-Pramaan ID. Correlation information will be stored at e-Pramaan only.

Users Registered to e-Pramaan and Enrolled to SP –

e-Pramaan sends one-time user- verification request to the SP. Once verified, SP will send the UserID and SP-ID to e-Pramaan for correlation.

Correlating is linking the username on the SP and e-Pramaan ID. Correlation information will be stored at e-Pramaan only.


User Profile Up-gradation User Profile Up-gradation

When the citizen registers to e-Pramaan her profile is registered for Level 1 and Level 2. To avail services mandating Level 3 and 4 authentication, user needs to upgrade her profile using Digital Certificate (DC) and Biometrics respectively.

Up-gradation to Level 3 – User should possess a Digital Certificate for qualifying for Level 3 up-gradation.

Digital Certificates issued by a licensed CA in India or e-Pramaan CA.

Only X.509 v3 Certificate will be recognized for authentication.

User can upgrade her profile to Level 3 by uploading the Public Key Certificate at e-Pramaan.

Up-gradation to Level 4 - Verification of user Biometric through Aadhaar is required for the user to complete the up-gradation to level 4.

When the citizen registers to e-Pramaan her profile is registered for Level 1 and Level 2. To avail services mandating Level 3 and 4 authentication, user needs to upgrade her profile using Digital Certificate (DC) and Biometrics respectively.

Up-gradation to Level 3 – User should possess a Digital Certificate for qualifying for Level 3 up-gradation.

Digital Certificates issued by a licensed CA in India or e-Pramaan CA.

Only X.509 v3 Certificate will be recognized for authentication.

User can upgrade her profile to Level 3 by uploading the Public Key Certificate at e-Pramaan.

Up-gradation to Level 4 - Verification of user Biometric through Aadhaar is required for the user to complete the up-gradation to level 4.


User Suspension & De-provisioningUser Suspension & De-provisioning

e-Pramaan has a functionality for suspending or de-provisioning a user. Suspension will result in user credential verification being blocked until reinstated while de-provisioning will result in credential revocation, thus permanently barring user to use them.

User account can be suspended or de-provisioned under any of the following scenarios:

De-provisioning initiated by User

Suspension initiated by SP / e-Pramaan administrator / Third Party Govt. Authority

Inactive Account Suspension initiated by e-Pramaan

e-Pramaan has a functionality for suspending or de-provisioning a user. Suspension will result in user credential verification being blocked until reinstated while de-provisioning will result in credential revocation, thus permanently barring user to use them.

User account can be suspended or de-provisioned under any of the following scenarios:

De-provisioning initiated by User

Suspension initiated by SP / e-Pramaan administrator / Third Party Govt. Authority

Inactive Account Suspension initiated by e-Pramaan


Step 1: SP should provide fields such as Organization type, Department name, Service name, Details of the administrator who will be operating the account, details of the contact person, Public Key Certificate of the service / department, official email ID and required authentication levels or chaining of authentication levels etc.

Step 2: Upon successful enlistment of SP, the MoU / Agreement is to be signed between e-Pramaan and SP.

Step 3: Integration of e-Pramaan with SP service shall be done.

Step 4: Upon successful completion of process described in Steps 2 and 3, the SP can start availing the authentication service.

Step 1: SP should provide fields such as Organization type, Department name, Service name, Details of the administrator who will be operating the account, details of the contact person, Public Key Certificate of the service / department, official email ID and required authentication levels or chaining of authentication levels etc.

Step 2: Upon successful enlistment of SP, the MoU / Agreement is to be signed between e-Pramaan and SP.

Step 3: Integration of e-Pramaan with SP service shall be done.

Step 4: Upon successful completion of process described in Steps 2 and 3, the SP can start availing the authentication service.

Service Provider EnlistmentService Provider Enlistment


Credential Handling in e-PramaanCredential Handling in e-Pramaan

PasswordPassword Setting RequirementPassword PolicyPIN

PIN GuidelinesOne Time Password (OTP) HMAC based OTP Time based OTP (TOTP) OTP Guidelines

Digital Certificates Issued by e-Pramaan CA Issued by Licensed Indian CA

PasswordPassword Setting RequirementPassword PolicyPIN

PIN GuidelinesOne Time Password (OTP) HMAC based OTP Time based OTP (TOTP) OTP Guidelines

Digital Certificates Issued by e-Pramaan CA Issued by Licensed Indian CAApril 19, 2023 © Centre for Development of Advanced Computing 11

MUST be associated with a user, only when the user has met all the predefined criteria for being considered as a part of e-Pramaan.

Reset functionality SHOULD be provided.

In cases where user chooses to reset the password, e-Pramaan SHOULD generate a random alphanumeric password for Reset purpose which is to be changed at first login after reset.

SHOULD NOT be displayed on screen.

MUST be associated with a user, only when the user has met all the predefined criteria for being considered as a part of e-Pramaan.

Reset functionality SHOULD be provided.

In cases where user chooses to reset the password, e-Pramaan SHOULD generate a random alphanumeric password for Reset purpose which is to be changed at first login after reset.

SHOULD NOT be displayed on screen.

PasswordPassword


The User Password

MUST Contain a minimum of 8 characters;

MUST Contain characters from the following categories

o English uppercase characters (A to Z)

o English lowercase characters (a to z)

o Numerals (0 to 9)

o Non-alphanumeric keyboard symbols (e.g. !@#&*)

MUST NOT contain the user’s name or any given surnames of the user.

The User Password

MUST Contain a minimum of 8 characters;

MUST Contain characters from the following categories

o English uppercase characters (A to Z)

o English lowercase characters (a to z)

o Numerals (0 to 9)

o Non-alphanumeric keyboard symbols (e.g. !@#&*)

MUST NOT contain the user’s name or any given surnames of the user.

Password Setting RequirementPassword Setting Requirement


After initial registration or reset password, user should be advised to change reset password after certain defined period.

Password MUST be stored with a one way hash value to prevent various password guessing attacks.

Password MUST be stored in the database ONLY in Message Digest format. SHA-2 algorithm is recommended for Hashing the Password.

Password MUST always be transmitted in encrypted format on all communication channels.

If Password is forgotten by the citizen, it MUST be RESET and MUST NOT be RECOVERED.

In cases of more than 3 unsuccessful authentication attempts by the user, the authentication system SHOULD display Captcha to be entered by the user and notification will also be sent to the verified mobile number and/or email id about the failed attempts.

After initial registration or reset password, user should be advised to change reset password after certain defined period.

Password MUST be stored with a one way hash value to prevent various password guessing attacks.

Password MUST be stored in the database ONLY in Message Digest format. SHA-2 algorithm is recommended for Hashing the Password.

Password MUST always be transmitted in encrypted format on all communication channels.

If Password is forgotten by the citizen, it MUST be RESET and MUST NOT be RECOVERED.

In cases of more than 3 unsuccessful authentication attempts by the user, the authentication system SHOULD display Captcha to be entered by the user and notification will also be sent to the verified mobile number and/or email id about the failed attempts.

Password PolicyPassword Policy


The PIN

MUST be set in numeric format only.

MUST be of 4-6 digits.

SHOULD be changed at regular intervals

SHOULD be RESET and not RECOVERD.

If 5 unsuccessful attempts are recorded, the account is to be locked.

The PIN

MUST be set in numeric format only.

MUST be of 4-6 digits.

SHOULD be changed at regular intervals

SHOULD be RESET and not RECOVERD.

If 5 unsuccessful attempts are recorded, the account is to be locked.

PIN GuidelinesPIN Guidelines


OTP schemes can be categorized into two types:

HMAC (Hash-based Message Authentication Code) based OTP known as HOTP HOTP algorithm is based on a counter value (C) and a static symmetric key (K) known only to the token

and the server. Both the token and the server will have the counter set with the same predefined initial value. In order to generate the HOTP value, the HMAC-SHA-1 algorithm is used which creates a 160 bits output. This value is truncated to a 6 digit OTP which can be easily entered by a user.

Time based OTP known as TOTP TOTP is the time-based variant of HOTP algorithm, which specifies the calculation of OTP value, based

on a representation of the counter as a time factor. The value T, derived from a time reference and a time step, replaces the counter C in the HOTP computation. TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions, based on SHA-256 or SHA-512 [SHA2] hash functions, instead of the HMAC-SHA-1 function that has been specified for the HOTP computation.

OTP schemes can be categorized into two types:

HMAC (Hash-based Message Authentication Code) based OTP known as HOTP HOTP algorithm is based on a counter value (C) and a static symmetric key (K) known only to the token

and the server. Both the token and the server will have the counter set with the same predefined initial value. In order to generate the HOTP value, the HMAC-SHA-1 algorithm is used which creates a 160 bits output. This value is truncated to a 6 digit OTP which can be easily entered by a user.

Time based OTP known as TOTP TOTP is the time-based variant of HOTP algorithm, which specifies the calculation of OTP value, based

on a representation of the counter as a time factor. The value T, derived from a time reference and a time step, replaces the counter C in the HOTP computation. TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions, based on SHA-256 or SHA-512 [SHA2] hash functions, instead of the HMAC-SHA-1 function that has been specified for the HOTP computation.

OTP SchemesOTP Schemes


e-Pramaan MUST ensure two-factor authentication with OTP instead of using OTP as a single factor authentication.

The Secret Seed values used for generating OTP MUST be stored securely.

The Shared Secrets used for generation of HOTP and TOTP at token and server MUST be stored securely.

The claimant (e.g., Token, Soft token) and Verifier (authentication or validation server) MUST be in time sync for TOTP generation.

An OTP generated should be valid only for a fixed time and SHOULD NOT be valid for more than one transaction.

e-Pramaan MUST ensure two-factor authentication with OTP instead of using OTP as a single factor authentication.

The Secret Seed values used for generating OTP MUST be stored securely.

The Shared Secrets used for generation of HOTP and TOTP at token and server MUST be stored securely.

The claimant (e.g., Token, Soft token) and Verifier (authentication or validation server) MUST be in time sync for TOTP generation.

An OTP generated should be valid only for a fixed time and SHOULD NOT be valid for more than one transaction.

OTP GuidelinesOTP Guidelines


Digital CertificatesDigital Certificates

e-Pramaan SHALL support certificates issued by licensed Indian CAs and e-Pramaan CA.

The Certificate Practice Statement (CPS) of e-Pramaan CA is based on the Certificate Practice (CP) and CPS of Root Certifying Authority of India (RCAI).

The SPs SHOULD decide whether they will accept the user authentication using e-Pramaan CA certificate or Licensed CA certificate.

The CPS for e-Pramaan CA SHALL be based on the CP of India PKI, CPS of RCAI and CPS of National Informatics Center- Certification Authority (NICCA).

Standards for Digital Certificates - Digital certificates generated and/or used in the authentication system should follow Controller of Certifying Authorities (CCA) India guidelines and X.509 /PKIX (X.509-based PKI).

e-Pramaan SHALL support certificates issued by licensed Indian CAs and e-Pramaan CA.

The Certificate Practice Statement (CPS) of e-Pramaan CA is based on the Certificate Practice (CP) and CPS of Root Certifying Authority of India (RCAI).

The SPs SHOULD decide whether they will accept the user authentication using e-Pramaan CA certificate or Licensed CA certificate.

The CPS for e-Pramaan CA SHALL be based on the CP of India PKI, CPS of RCAI and CPS of National Informatics Center- Certification Authority (NICCA).

Standards for Digital Certificates - Digital certificates generated and/or used in the authentication system should follow Controller of Certifying Authorities (CCA) India guidelines and X.509 /PKIX (X.509-based PKI).


e-Pramaan CA - The e-Pramaan CA will be based on the Hierarchy based closed PKI model and will issue certificate using its Self-Signed RootCA. e-Pramaan CA certificates will be issued based on the e-Pramaan CA CPS. The Digital Certificate will be issued only after verifying either Aadhaar number or PAN of the user. In addition, more documents may be asked for verification purposes as the case may be.

Licensed Indian CA - CAs in India follow the Hierarchical Model for issuing a certificate as per the IT Act 2000. The certificate issuance is based on their respective CPS which is prepared based on the CP of CCA. The CAs in India issues different types of certificates such as Signing, Encryption, Code Signing, SSL certificate etc. However, e-Pramaan SHALL accept only Signing Certificates for user authentication.

e-Pramaan CA - The e-Pramaan CA will be based on the Hierarchy based closed PKI model and will issue certificate using its Self-Signed RootCA. e-Pramaan CA certificates will be issued based on the e-Pramaan CA CPS. The Digital Certificate will be issued only after verifying either Aadhaar number or PAN of the user. In addition, more documents may be asked for verification purposes as the case may be.

Licensed Indian CA - CAs in India follow the Hierarchical Model for issuing a certificate as per the IT Act 2000. The certificate issuance is based on their respective CPS which is prepared based on the CP of CCA. The CAs in India issues different types of certificates such as Signing, Encryption, Code Signing, SSL certificate etc. However, e-Pramaan SHALL accept only Signing Certificates for user authentication.

Digital CertificatesDigital Certificates


Digital Certificate RevocationDigital Certificate Revocation

Digital Certificate SHALL be revoked by e-Pramaan, at its absolute discretion, or on receipt of revocation request from the following:

The authorized user e-Pramaan CA e-Pramaan A sensitive Govt. Agency dealing the National Security

Digital Certificate will be revoked if:User’s Private Key is compromised or misused. User’s Private Key is suspected to be compromised or misused. The User’s information in the Certificate has changed. The User is known to have violated the rules and regulations laid by e-Pramaan CA. The User wishes to deactivate her e-Pramaan account. The User certificate is expired.

Digital Certificate SHALL be revoked by e-Pramaan, at its absolute discretion, or on receipt of revocation request from the following:

The authorized user e-Pramaan CA e-Pramaan A sensitive Govt. Agency dealing the National Security

Digital Certificate will be revoked if:User’s Private Key is compromised or misused. User’s Private Key is suspected to be compromised or misused. The User’s information in the Certificate has changed. The User is known to have violated the rules and regulations laid by e-Pramaan CA. The User wishes to deactivate her e-Pramaan account. The User certificate is expired.


Biometrics Biometrics

User biometric data is validated by Aadhaar through an Authentication Service Agency (ASA). On successful validation of the biometric credentials at Central Identities Data Repository (CIDR), e-Pramaan returns a successful authentication message to the service.

Standards for BiometricsFingerprint biometric information captured by the system MUST be compliant with the standards

as specified by Unique Identification Authority of India (UIDAI) for Aadhaar authentication.

e-Pramaan SHALL not store any biometric data of the user.

Biometric information of the user SHALL be forwarded to CIDR on a secured communication channel as specified by UIDAI.

User biometric data is validated by Aadhaar through an Authentication Service Agency (ASA). On successful validation of the biometric credentials at Central Identities Data Repository (CIDR), e-Pramaan returns a successful authentication message to the service.

Standards for BiometricsFingerprint biometric information captured by the system MUST be compliant with the standards

as specified by Unique Identification Authority of India (UIDAI) for Aadhaar authentication.

e-Pramaan SHALL not store any biometric data of the user.

Biometric information of the user SHALL be forwarded to CIDR on a secured communication channel as specified by UIDAI.


Identity Attributes in e-Pramaan Identity Attributes in e-Pramaan

Single Sign-on and Assertion

When an authentication event is successful, the result of the authentication MUST be communicated to the SP department application or service in the form of an assertion

The assertion states who the user claims to be, the attributes of the user etc. The assertion mechanism involves securely communicating this assertion and allowing it to expire after a period of time

e-Pramaan SHALL use the Security Assertion Markup Language (SAML v2.0) for accomplishing this.

Single Sign-on and Assertion

When an authentication event is successful, the result of the authentication MUST be communicated to the SP department application or service in the form of an assertion

The assertion states who the user claims to be, the attributes of the user etc. The assertion mechanism involves securely communicating this assertion and allowing it to expire after a period of time

e-Pramaan SHALL use the Security Assertion Markup Language (SAML v2.0) for accomplishing this.


Credential Min Length

Max Length

Required (Yes/No)

Format Validations

Given Name (First Name + Middle Name)

2 99 Yes Combination of English alphabet separated by “blank space” representing given name/middle name/….etc in any order as per cultural practices.

Last name 2 50 No Combination of English alphabet separated by “blank space” representing, etc in any order as per cultural practices.

Address (All specifications taken from the Demographics Standards [10] with the exception that Sub-District has not been taken separately, it is assumed that if required it will be given as part of the Locality).

House 1 60 Yes Alphanumeric and special characters ();-.



The following tables enlists the credentials of the e-Pramaan user accepted during Registration


Max Length

Required (Yes/No)

Format Validations

Street 1 60 No Alphanumeric and special characters ();-.

Locality 1 60 No Alphanumeric and special characters ();-.

City / District 1 50 Yes Letters of English Alphabet

State 1 50 Yes Character Set – selected from a pre-populated list

Pincode 6 6 Yes Numeric

Date Of Birth 10 10 Yes dd/mm/yyyy format.

User Name 3 100 Yes As per specifications in Section 3.1




Max Length

Required (Yes/No)

Format Validations

Password 8 30 Yes As per Specifications in Section 3.2

Mobile Number 14 14 No Numeric.

Mobile number or e-mail ID: one of them is mandatory

e-Mail ID 5 254 No Alphanumeric in valid email-ID format.

Mobile number or e-mail ID: one of them is mandatory

PAN Card Number

10 10 No Alphanumeric in standard PAN Card Number Format

Aadhaar Number 12 12 No Numeric, display format NNNN-NNNN-NNNN.



Session Policy Management Session Policy Management

Assertion Attributes

Assertion attributes MAY contain parameters such as Primary communication IDs, Session details and other parameters (if any). These Assertion attributes MUST be sent in the form of Authentication Token.

Post-Authentication Action

On successful authentication, e-Pramaan will create an Authentication Token and communicate it to the SP. SP checks validity of the Authentication Token and availability of required assertion attributes before providing access to user account.

Session Logout Policy

Once the user is logged-out from either e-Pramaan or any other service accessed through e-Pramaan, the user MUST be logged-out from all the authenticated services.

Assertion Attributes

Assertion attributes MAY contain parameters such as Primary communication IDs, Session details and other parameters (if any). These Assertion attributes MUST be sent in the form of Authentication Token.

Post-Authentication Action

On successful authentication, e-Pramaan will create an Authentication Token and communicate it to the SP. SP checks validity of the Authentication Token and availability of required assertion attributes before providing access to user account.

Session Logout Policy

Once the user is logged-out from either e-Pramaan or any other service accessed through e-Pramaan, the user MUST be logged-out from all the authenticated services.


Communication and SecurityCommunication and Security

Communication between the authentication system and the service may use PKI or symmetric keys or hybrid methods.

Messages SHALL be encrypted either RSA-2048 or Elliptic Curve Cryptography (ECC) if PKI solution is used or AES algorithm if symmetric key protocol is used.

e-Pramaan SHALL support two way SSL communications with the backend services to provide an encrypted channel with secure transmission of data.

Communication between the authentication system and the service may use PKI or symmetric keys or hybrid methods.

Messages SHALL be encrypted either RSA-2048 or Elliptic Curve Cryptography (ECC) if PKI solution is used or AES algorithm if symmetric key protocol is used.

e-Pramaan SHALL support two way SSL communications with the backend services to provide an encrypted channel with secure transmission of data.


Service Agreements Service Agreements

Legal Compliance Requirements The SPs MUST comply with relevant Indian law, including the Information Technology Act (IT Act) 2000 and IT Act

2008 Amendment.

Service Design Requirements Acceptability Security and Privacy

e-Pramaan Service Requirements Affordability, Reliability and Timeliness Complaints handling Fraud and Incident Management

User Agreements and Notification Requirements User Agreements Notification

Legal Compliance Requirements The SPs MUST comply with relevant Indian law, including the Information Technology Act (IT Act) 2000 and IT Act

2008 Amendment.

Service Design Requirements Acceptability Security and Privacy

e-Pramaan Service Requirements Affordability, Reliability and Timeliness Complaints handling Fraud and Incident Management

User Agreements and Notification Requirements User Agreements Notification


Audit Trail Management Audit Trail Management

Types of Events Recorded: e-Pramaan Servers Start-up and Shutdown.

User Login and Logout, successful and failed attempts to e-Pramaan.

Attempts to reset passwords.

Unauthorized attempts at network to access e-Pramaan servers.

Unauthorized attempts to access protected data.

Protection of Audit Log

Audit Log Backup Procedures

Vulnerability Assessments

Types of Events Recorded: e-Pramaan Servers Start-up and Shutdown.

User Login and Logout, successful and failed attempts to e-Pramaan.

Attempts to reset passwords.

Unauthorized attempts at network to access e-Pramaan servers.

Unauthorized attempts to access protected data.

Protection of Audit Log

Audit Log Backup Procedures

Vulnerability Assessments April 19, 2023 © Centre for Development of Advanced Computing 29

Thank YouThank You


e-pramaan standards & specifications 19 september 2015 © centre for development of advanced...

Documents