Security Guidelines_V1.
All the information in this document is confidential and privileged information and related to
smartData Enterprise (I) Ltd. Data and Information provided only for smartData use only. Its
data and contents cannot reproduce without smartData concern and permission of smartData
authority. Any unauthorized review; use, disclosure or distribution is prohibited.
Revision History
Revised By Revised On Version Comments
Vinod Sharma 29 _Oct-2016 1.0 Initial version of the document
Deepika Joshi 18-Feb-2020 1.1 Section 2 .Procedure- Added
section number and heading
for the reference
Table of Contents
1. OBJECTIVE ............................................................................................................................... 2
2. SCOPE .......................................................................................................................................2
3. Procedure.............................................................................................................................2
4 Security Specification and Implementation..........................................................................................2
4.1 Access Layer..........................................................................................2
4.2 Database layer..........................................................................................2
4.3 Data Transmission layer..........................................................................................3
5. Further References/Links..........................................................................................3
Security Guidelines_V1.0
1. Objective
The objective includes the measures taken throughout the code's life-cycle to prevent gaps
in the security policy of an application or the underlying system (vulnerabilities) through
flaws in the design, development, deployment, upgrade, or maintenance or database of the
application.
2. Procedure
Security level required in the application will be determined at time of BKO.
Security measures will be mentioned in PMP under NON-Functional Requirements
section 11.3 Quality Attributes
Evidence of testing for the same is required to be maintained in the form of
screenshot/checklist.
Product owner confirms the security measures proposed by the Scrum
Master/Product Owner
Security implementation is validated at the time of Board Review/Project
Review/SQA Audit.
3. Scope
The scope of this document covers organizational level security provided at different level of
project development lifecycle.
4. Security Specification and Implementation
As per SDEI Software security is defined at three levels.
Access Level
Database level
Data Transmission.
4.1 ACCESS Level: - is the selective restriction of access to a place or other resource. The
act of accessing may mean consuming, entering, or using. Permission to access a
resource is called authorization.
Implementation Practices/Techniques/Tools
1. Application shouldn’t allow unauthorized users to access the restricted areas of the
application.
2. For applications having backend interface to manage different features by default all
applications should have separate sub administrator (role based access
management).
Security Guidelines_V1.0
3. Applications which requires access to the database should be setup in such a way
that the database user through which application is being configured shouldn’t have
all the permissions which are beyond than what is needed to run the application e.g.
in most of the cases there is no need to drop a database, alter a database or
truncate database using application user so the permissions should be setup
accordingly only.
4. The directories of the server shouldn’t be setup with writeable permission.
Permissions of the files and folders should be minimum what is needed to run the
application.
5. Directories listing on server should be always disabled.
Tools: SSH, Putty, in built role based access management system in SDEI framework.
4.2 Database Level: - concerns the use of a broad range of information security controls to
protect databases (potentially including the data, the database applications or stored
functions, the database systems, the database servers and the associated network links)
against compromises of their confidentiality, integrity and availability. It involves various
types or categories of controls, such as technical, procedural/administrative and
physical.
Implementation Practices/Techniques/Tools
Encryption, Masking, tokenization etc. are mechanisms of database security.
.
1. All passwords of the users should be stored in encrypted format (one way
encryption only) within the database. The encrypted string should be generated
using strong hashing functions, which shouldn’t be possible to decrypt again.
2. Server where database of the application is setup shouldn’t be accessible through
any other server other than the one where code of the application is hosted.
3. There should be automated database backups taken at regular intervals to ensure
that it can be recovered in case something goes wrong. In addition to this the
customer should be made aware about this in case SDEI is not responsible for
managing this.
4. Similar the security patches should be applied to the database server as well apart
from the application server from time to time to ensure that it is safe from outside
intruders.
Tools: SSH, Putty, Phpmyadmin, Rsync (use equivalent command on windows platform),
server administrator to keep OS up to date. Refer Linux commands depending upon the
OS flavor used (e.g. http://www.mediacollege.com/linux/command/linux-
command.html
4.3 Data Transmission level: - Transmission security (TRANSEC) is the process of securing
data transmissions from being infiltrated, exploited or intercepted by an individual,
application or device. TRANSEC secures data as it travels over a communication
medium.
Implementation Practices/Techniques/Tools
Security Guidelines_V1.0
Information Leak Prevention, Content Monitoring and Filtering etc. are mechanisms of Data
Transmission security.
1. Application server should be configured with firewalls for added security.
2. All pages which involves sensitive information about the customers eg. Sign in, sign
up, payment gateway, account settings etc. should be configured to run only on
HTTPS connection.
3. Proper attention should be paid to the kind of data which application stores in the
cookies. It shouldn’t store passwords, hashes or other sensitive information in the
cookies.
4. Application should be developed in a way to taken care of common security issues
e.g. CSRF attacks, XSS attacks, Cookie hijacking.
In case we are not managing customer’s server for additional security measures we need to
communicate consequences of not keeping server up to date with the customer as well
so that they can get it configured through managed hosting.
Tools: configure firewalls through managed hosting, SSH, Putty
5. Further References\Links:-
https://www.toptal.com/security/10-most-common-web-security-vulnerabilities
http://searchsecurity.techtarget.com/tip/Five-common-Web-application-vulnerabilities-and-how-to-avoid-them
https://www.qualys.com/research/top10/
https://www.us-cert.gov/ncas/alerts/TA15-119A
https://blog.spamexperts.com/2016/01/19/how-to-keep-your-server-safe-in-a-few-simple-steps/
