Date: Fri, 29 Mar 2024 15:39:35 +0000 (UTC) Message-ID: <1338782884.19.1711726775352@fb6c5a1615ee> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_18_945748734.1711726775352" ------=_Part_18_945748734.1711726775352 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page is about the openIMIS applications, for the infrastruc= ture security, please check this page: Infrastruc= ture security
Here are a number of points that can be assessed in order to strengthen = the system security. These are only a few basic indicators to get started, = however, securing an online application will require constant updates and c= hecks from the system admins to comply with the latest standards.
[Example of assessment grades: not implemented, implemented,&n= bsp;partially implemented, in implementation, to be clarified]
ID |
Group |
Type |
Description |
Assessment |
---|---|---|---|---|
1 |
Technical Implementation |
Authorization |
Role-based security is used in the web-application to differentiate user= s that can read data, users that can write data and users that can configur= e/administer the system. |
|
2 |
Technical Implementation |
Authentication |
Users are authenticated through username and password when accessing the= software. |
|
3 |
Technical Implementation |
Authentication |
Usernames are limited to the following characters: A-Z, a-z, 0-9 |
|
4 |
Technical Implementation |
Authentication |
The application has login and logout functionalities. |
|
5 |
Technical Implementation |
Authentication |
Logout functionality is available in all the pages of the web-applicatio= n. |
|
6 |
Technical Implementation |
Authentication |
Application access passwords should have at least 8 characters long and = at least one of the following character sets: space, A-Z, a-z, 0-9, !"#$%&a= mp;'()*+,-./:;<=3D>?@[\]^_`{|}~ |
|
7 |
Technical Implementation |
Authentication |
Application access passwords do not use dictionary words. |
|
8 |
Technical Implementation |
Authentication |
Application access passwords must be changed every 2 months, otherwise u= ser access is blocked. |
|
9 |
Technical Implementation |
Authentication |
Accounts that have not logged in for 2 months are blocked. |
|
10 |
Technical Implementation |
Authentication |
After 3 wrong passwords are entered for a valid login within one day, th= e respective user account is blocked. |
|
11 |
Technical Implementation |
Authentication |
After 10 minutes of innactivity the user is logged out. |
|
12 |
Technical Implementation |
Authentication |
=E2=80=98Admin=E2=80=99 or =E2=80=98Administrator=E2=80=99 logins do not= exist. An administrator (user that can access the application administrati= on area) has a regular account name as any other user (e. g.: =E2=80=98gcas= tro=E2=80=99), the only difference being in the privileges that are granted= . |
|
13 |
Technical Implementation |
Authentication |
User with administration role has to provide his login and password agai= n when performing administration actions that imply the change or deletion = of data. |
|
14 |
Technical Implementation |
Auditing |
The web-application has Audit Trail functionality that records WHO did W= HAT (data entered/changed/deleted, configurations changed, logins, logouts)= and WHEN (server timestamp). No debug messages are recorded. Only new info= rmation can be written and older records cannot be rewritten or delete. The= Audit Trail is only accessed by administrators. |
|
15 |
Technical Implementation |
Authorization |
Only users with Administrator role can access the Audit trail. |
|
16 |
Technical Implementation |
Authorization |
Only system administrators can unblock an account. |
|
17 |
Technical Implementation |
Authorization |
To run the application or connect it to webserver or database the least = privileged accounts possible are used. |
|
18 |
Technical Implementation |
Authorization |
User accounts are assigned just enough privileges to perform their tasks= . |
|
19 |
Technical Implementation |
Authorization |
Users are not administrators or vice versa. |
|
20 |
Technical Implementation |
Encryption |
Patient identification data is transmitted encrypted. |
|
21 |
Technical Implementation |
Encryption |
Patient identification data is stored encrypted in the database. |
|
22 |
Technical Implementation |
Encryption |
User credentials are transmitted encrypted. |
|
23 |
Technical Implementation |
Encryption |
User credentials are stored encrypted in the configuration files and in = the database. Files containing cryptographic keys have restrictive file per= imissions. |
|
24 |
Technical Implementation |
Encryption |
Data encryption is performed using proven cryptographic services provide= d by platform (e. g.: OpenSSL) |
|
25 |
Technical Implementation |
Client-Server Communication |
The web-application runs over HTTPS and each user has his own HTTPS cert= ificate that authentifies him/her when interacting with the application ser= ver. |
|
26 |
Technical Implementation |
Client-Server Communication |
HTTP POST is used instead of GET to submit forms. |
|
27 |
Technical Implementation |
Exceptions |
Exceptions thrown during application execution are handled and logged; a= nd only generic, harmless error messages are returned to the user. |
|
28 |
Technical Implementation |
Validation |
All input available in the web-application (query strings, form fields, = cookies) are validated for type, length, format and range in the different = software layers. |
|
29 |
Documentation |
Manuals |
User Manual (detailing how to use the system) exists. |
|
30 |
Documentation |
Manuals |
Technical Manual (detailing system architecture, installation/configurat= ion and maintenance) exists. |
|
31 |
Physical Infrastructure |
Server rooms |
The servers in which the application is deployed are physically located = in self-purpose server rooms. |
|
32 |
Physical Infrastructure |
Server rooms |
The server rooms are locked and only authorized personnel can access the= m. |
|
33 |
Physical Infrastructure |
Server rooms |
The server rooms have a constant temperature around 20-21=C2=B0C. |
|
34 |
Physical Infrastructure |
Server rooms |
The server rooms have fire prevention systems (such as alarms or fire ex= tinguishers). |
|
35 |
Physical Infrastructure |
Server rooms |
The server rooms have cleared walking pathways for personnel, in order t= hat these do not face the risk of tripping on cables or devices. |
|
36 |
Physical Infrastructure |
Server rooms |
Physical access to devices interfaces and cables within the server rooms= are possible without moving equipment. |
|
37 |
Physical Infrastructure |
Server rooms |
Server rooms are professionally cleaned at least once every three months= . |
|
38 |
Physical Infrastructure |
Equipment |
Electrical devices in the server rooms are protected against voltage spi= kes (e. g.: through a surge protector). |
|
39 |
Physical Infrastructure |
Equipment |
In the event of a power failure, power supply is still assured for the e= lectrical equipment in the server rooms (through uninterruptible power supp= ly (UPS) and/or a backup generator) |
|
40 |
Physical Infrastructure |
Equipment |
Cables are not stretched, tightly tied or bended. |
|
41 |
Physical Infrastructure |
Equipment |
Cables running in parallel are tied together. |
|
42 |
Physical Infrastructure |
Equipment |
Technical manuals are available for the devices present in server rooms.= |
|
43 |
Physical Infrastructure |
IT Infrastructure |
Servers heat dissipation exits are not blocked. |
|
44 |
Physical Infrastructure |
IT Infrastructure |
Hardware firewalls are used at the "entry" of the clients and servers ne= tworks and are properly configured in order to analyse and filter data pack= ets. |
|
45 |
Physical Infrastructure |
IT Infrastructure |
The servers where the application is deployed use disk protection techno= logy such as RAID. |
|
46 |
Infrastructure - Network |
Concept |
An Intrusion Detection and Prevention System is operational within clien= t and server networks in order to monitor network and/or system activities = for malicious activities and policy violations. |
|
47 |
Infrastructure - Network |
Configuration |
Routers at the networks at client and server sides are configured to res= trict their responses to footprinting requests. |
|
48 |
Infrastructure - Network |
Configuration |
Operating systems at client and server sides are configured to prevent f= ootprinting by disabling unused protocols and services as well as unnecessa= ry ports. |
|
49 |
Infrastructure - Network |
Configuration |
Routers at the entry of the network at client and server levels filter i= ncoming packets that appear to come from an internal IP address of the netw= ork. |
|
50 |
Infrastructure - Network |
Configuration |
Routers at the entry of the network at client and server levels filter o= utgoing packets that appear to originate from an invalid local IP address.<= /p> |
|
51 |
Infrastructure - Host |
Required software |
Required software to run the application (operating system, frameworks, = etc.) is installed and configured. |
|
52 |
Infrastructure - Host |
Required software |
Anti-malware & anti-virus software is installed at both server and c= lient machines. |
|
53 |
Infrastructure - Host |
Authentication |
Passwords to access servers, client computers and supporting software (e= . g.: database management system) must include at least 8 characters, inclu= ding numbers, both upper and lower case letters, and specials characters.= p> |
|
54 |
Infrastructure - Host |
Authorization |
System commands, files and utilities within the servers are locked down = with restricted Access Control Lists. |
|
55 |
Infrastructure - Host |
Configuration |
Web server application rejects URLs with =E2=80=9C../=E2=80=9D. |
|
56 |
Infrastructure - Host |
Configuration |
Functionality that enables the user to ask the browser to remember his/h= er credentials (login, password) for application access is disabled. |
|
57 |
Infrastructure - Host |
Configuration |
Application configurations are not accessible to anyone besides system a= dministrators and the application itself. |
|
58 |
Processes |
SOPs |
Relevant operational SOPs are available (for Backup and Restore procedur= es, Disaster Recovery, Incident Management, Operational Change & Config= uration Management, Performance Monitoring, Security Management, System Adm= inistration, User Support) and are followed. |
|
59 |
Processes |
Backups |
Data backups are automatically performed every night on the =E2=80=98pro= duction=E2=80=99 data (including application data, configurations and audit= trail records) and stored in more than one geographical location. |
|
60 |
Processes |
Required software |
Required software to run the application (operating system, frameworks, = etc.) on the server and on the client machines is not updated automatically= , and is tested before deployment. |
|
61 |
Processes |
Privileges |
Users receive a security role within the application that uniquely allow= s them to perform their work and nothing more. |
|
62 |
Processes |
Configuration |
Security related configuration settings for software and hardware device= s is reviewed for adequacy at installation and at least twice per year. = |
|
63 |
Processes |
Authentication |
Application logins are unique for each user. There are no shared logins.= |
|
64 |
Processes |
User Behaviour |
Logout: user is recommended to close session and clear any cookies left = on the browser |
|