Security draft

security/application.md

@@ -0,0 +1,33 @@
+# Application Security
+
+## Passwords
+
+While the application allows to fully customize the password policies it is recommended to not weaken the default settings too much.
+
+### Structure
+
+The password structure is a highly discussed topic however a password with
+
+* At least one upper case letter
+* At least one lower case letter
+* At least one numeric character
+* At least one special character
+* At least 8 characters
+
+is one of the business standards. Longer passwords may be required in the future. Just as a quick info in order to convey the importance of these suggestions, a 8 character password with only upper and lower case characters can be found in less than 6 hours. More and different (like numeric and special) characters exponentially increase the time that is required to brute force a password.
+
+### Aging
+
+Passwords should be changed every 3 month. Enforced password changes are very common and prevent people from using the same passwords over a long period and potentially also for many other applications/services. More important this prevents people from using their standard password which they may use at home in a much less secure environment.
+
+## Permissions
+
+The application allows permission handly by user groups and directly by users. It is strongly recommended to lay out a basic organisation schematic and job description for every area. Based on these job descriptions groups should be generated. The permission management through groups is preferred since it's much more verbose and shows a clear structure. While permissions on user basis are in some cases more convenient for quick permission handling they indicate that the actual job function compared to the organization layout is not coherent with the actual tasks that person is performing. Permission handling on user level is strongly advised against and restructuing groups and creating new groups is much cleaner even if in some cases a group only has one account assigned. Permissions for accounts should also get re-evaluated on a regular basis in order to prevent non-active accounts or accounts whose job description changed to have permissions they no longer need.
+
+## Updates
+
+Updates are very important not only to implement the newest features but also to close potential security vulnerabilities. Depending on your server environment automatic security updates can be activated which then will be executed once a day. Alternatively these updates should be performed manually on a regular basis.
+
+## Modules, Extensions, Themes etc.
+
+Only download software components from the official website never trust any third party services. All software components on the official website get tested and reviewed internally in order to ensure no malicious behavior.

security/mentality.md

@@ -0,0 +1,21 @@
+# Security Mentality
+
+Security layers and guidelines are usually seen by the every day user as necessary evil. However without a good mindset no amount of guidelines or even technical security measurments will protect the integrity of the server and data. The thought process often goes along these lines:
+
+1. I will not get attacked!
+2. I don't have any data that need protection!
+3. Why would someone be interested in our data?
+4. My actions can't have severe security implications!
+5. What could actually happen to me personally?
+6. But it is so annoying and time consuming!
+
+Here are some of the responses to such a mentality:
+
+1. You will. Hundreds of attacks get executed on simple personal web pages which really don't have any interesting data on them. Many attacks are automated and don't even require any man power, starting with simple password attacks.
+2. Just because you don't think these data need protection doesn't mean other people will think the same. You may not care if someone get's access to your personal information but your actions could actually allow attackers to gain access to personal information of other people that may very well think differently from you.
+3. "Some people just want to watch the world burn" and others hope to gain some monetairy benefit from either returning the data or not publishing the information from you on the internet.
+4. How can you know this? Unless you've a fundamental IT understanding of the network, permission and application structure you will most definately not know where your seemingly minor security infringement could cause severe damages. Even server administrators or software developers may not see the implications in their own network/application at first and you believe you can?
+5. As an employee you could get fired for careless behavior or depending on your residence even face legal actions. As server administrator or company owner you'll most definately be legally responsible for all kinds of security infringements (even if they are executed by your employees or indirectly caused by third parties).
+6. It is way more time consuming calling your employees, customers, suppliers that their information have been compromised. In case of data loss you'll have to pay large sums for data recovery, potential legal fees etc.
+
+A guideline and training for IT security and user data is a must for every person but it's much more important to live these security guidelines in a top down approach. Only if the management has a positive attitude towards them the other employees will follow. As soon as someone doesn't understand a certain guideline make sure to explain them the reason behind it and if you hear someone complaining about it try to change their oppinion by conveying your positive view. Even by just agreeing that they are annoying the management or team leaders can undermine the integrity of the policy.

security/server.md

@@ -0,0 +1,34 @@
+# Server Security
+
+Since server security or operating system security is a very large topic this chapter only provides a rough schematic of some best practices which you should look up on the internet. These are the most common practices and are well documented in many online documentations for multiple operating systems. While these practices and guidelines are the basics for most server administrators they may seem to be confusing or unnecessary for people that have never managed their own server. If you are only using standard webhosting with a simple ftp upload and database system and no ssh or vnc login (vps, root server etc.) the following guidelines don't apply since this should have been already done by any responsible webhost provider.
+
+## Access Restrictions
+
+In general only whitelist user access permissions instead of blacklisting them. In other words don't be afraid to create multiple accounts or user groups for single applications and only give them reading/writing/execution permissions to directories and files they need access to. In case of our applications make sure the virtual user which is running the web server and hence these applications only has permissions to directories and files that it requires. It also doesn't hurt to create different accounts for different applications (web applications, socket applications). This is smart especially since the socket applications require different permissions than the web applications and there is no good reason to give the user account responsible for running the web applications permissions that it doesn't need just so you don't have to create another user or user group for the socket applications.
+
+## HTTPS
+
+HTTPS is a protocol or form of encrypted communication between client and server. It prevents attackers from reading the data beeing sent back and forth between server and client, which can be very critical when we are talking about user, company, customer, employee, private information. Nowadays it's fairly simple and cheap to setup and a must have for every website and application that is accessible through the internet browser. It is recommended to use the free service of Let's encrypt. Since https is a matter of server configuration this cannot be achived by the application itself. Follow the step-by-step instructions of https://certbot.eff.org/ in order to setup https for your own server. Normal webhosting services usually optionally offer https for a premium which you should definately consider. While you'll most likely have to pay your webhosting agency they will do the setup for you. Just remember that the actual certificate can be optained for free and while services may try to sell you more expensive certificates they are essentially the same as the free alternative.
+
+## Root Login
+
+By deactivating root login you can at least prevent yourself from potentially breaking critical system configurations by accident and much more important even if your login credentials get compromised an attacker will be restricted to the permissions of that account while the administrator/root access would compromise not only the files and areas of the web application but also all other programs and directories or in case of a shared server you would also open all doors for attackers to these user files/information.
+
+## Updates
+
+Keep your software updated. This doesn't only apply for the operating system but also all the other software you may be running. A chain is only as strong as it's weakest link and if one of your software components has a security vulnerability this could be potentially used to infect the whole system.
+
+## Login
+
+Implement passwordless login. This way you don't login into your server by using a login password but by generating a specific authentication key. This can be achieved by using ssh authentication and provides another layer of security to your server. At least implement some form of password policy which requires you to change your passwords from time to time.
+
+## Other
+
+There are still many more uncovered topics and tools which definately are worth reading up on.
+
+*. Iptables
+*. Monitoring
+*. fail2ban
+*. UFW
+*. Intrusion detection system
+*. SFTP vs FTP