Reducing Security Vulnerabilities for Parking Management Systems
It is important to understand security vulnerabilities for parking management as you might think that hackers are not interested in your parking management system, but they are. The information you collect on vehicles and individuals is the kind of data that hackers are looking for.
While the bad guys might initially intend on hacking to access free parking, they might be tempted by the other information you have while they are at it.
The good news is that a good parking management solution has built-in security features that offer organizations a level of protection. However, how you use that software and the policies you implement for its use are more important than the security features themselves.
Protecting Your Data
Did you know that 75% of consumers reuse the same password across multiple sites?
If someone gains access to your system and found a name and password of someone who used your system to pay a violation, would that give them a leg up for gathering more information on that person? It is very possible. When users of your system create accounts, they expect that you will keep their information secure.
Security Vulnerabilities for Parking Management
Your parking management software is no different from any other system you implement in your operations. It contains essential information, and you need to take the right steps to protect it. In general, many of the best practices we have included below can apply to other systems you operate as well. However, as we roll out our enhanced security features for our OPS-COM solution, we recognize that some of these steps are often missed within parking management departments but are all critical for system security.
1. Who has access to what?
Most systems should have regular account audits to determine who has access to what components of your system to make sure the right permissions are in place. It is also essential to keep track each time you grant or remove access. Account audits help you identify errors in access privileges such as failures to delete accounts of past employees, failures to change privileges when an employee changes roles, or not granting sufficient access to new employees. It also lets you see if someone has access to something he or she does not need. An employee who logs violation payments most likely doesn’t need to have privileges to change or create reports for example.
Not everyone needs access to your full parking software so you should grant privileges based on the individual users specific roles. By creating role profiles, you can categorize your users based on what they have access to. For example, you might create roles for “Patrol” or “Clerk” or “Administrator” all with different levels of access and privilege. This also helps simplify your account setup by eliminating the need to pick through a list of permissions for each employee account.
2. Mandate password policies
According to the Verizon report 2016 Data Breach Investigations Report, 63% of confirmed data breaches were the result of weak, default, or stolen passwords. We all suffer from password overload. If users are logging into your parking management system using their original default password because they never bothered to change it, or using a common password that’s easy for hackers to guess, they are a liability. According to SplashData which does an annual report on the worst passwords, in 2015, the two most common passwords in use were “123456” and “password.” Hackers will not have a hard time guessing these.
To help minimize the risk of employee-managed passwords, it is a good idea to put password policies in place that include the following:
- Minimum requirements for passwords should consist of a minimum number of characters and a need for a variety of characters including numbers, upper case letters, or symbols.
- Set a maximum password age that requires users to change their passwords periodically; anywhere from 30 to 90 days is standard for environments where there are high-security concerns. As much as 180 days are adequate for others.
- Be sure employees understand they are accountable for the security of their passwords. They should have a sense of responsibility for what happens if finds their password and accesses the system fraudulently. They should know not to share passwords or leave it written where someone else can see them.
- Don’t send new passwords via an unsecured email. For forgotten passwords, establish a process to send links to a secure page for employees to reset a password.
- Enforce your password policy through automation as much as possible. Be sure employees are aware of the policy and the implications if they choose not to be compliant.
3. Store passwords using hashed and salted encryption
Stored in the system are all the usernames and passwords your employees use to log into your parking management software. If someone were to access that data, he or she would have access to everyone’s login credentials. More and more, systems are using salted password hashing to add an extra layer of security to storing passwords.
Hashing is a one-way, irreversible process that takes the password a user enters and converts it into a short-value hash that remains in the system. For example, if a user enters their password as F23n$gh7, the hashing process might convert it into a four-digit number like 4792 and store that in the system.
If by coincidence, another user chooses the same password, with only hashing in place, the same 4792 would remain in the system for the second user. That brings in the salting process, which will randomize the string of digits for the hash so that even if two users have the same password, they will have different hash strings. It is not possible to reverse a hash so you cannot “look up” what the original password was. Instead, a user who forgets their password, for example, would have to reset it completely.
Why is this important? For many reasons. If a hacker accesses the username and password portion of your system, the process of deciphering salted password hashes would be almost impossible. This also limits an administrator’s ability to view the passwords of employees, which can also be a security vulnerability.
4. Monitor login activity and configure lockout options
Reviewing login data is an excellent way to identify emerging issues. If you see an employee’s credentials used outside of their shift hours, it may be a sign of a stolen or hacked password or unauthorized access by the employee. In these examples, you will want the ability to lock out the account, temporarily or permanently, so you can investigate further.
Lockout options can also restrict IP addresses that you do not want to access your system. A common example is limiting a geographical region from which someone can log in. If you are located in Canada for example, you can lock out IP addresses outside of Canada. You know none of your employees will need to log in from out of the country. This helps prevent overseas hackers from logging into the system using stolen passwords.
5. Make security training a core part of user training
Be sure you have formal training in place for your team. As a result, they do not become a liability for your system. Different users will have different needs so you may want to consider customized training for different roles and permissions. The training does not have to be complicated. It should be comprehensive and revisited every year with either a refresher or updates based on any changes to the system. If you are not comfortable with all the nuances, you can look to others for support. We, for example, offer training on our OPS-COM products, so you do not have to develop it yourself.
6. Look to 3rd party payment solutions
To avoid the liability of keeping payment information secure on your own network, look to integrate with a hosted payment solution like PayPal, Moneris, Chase PaymenTech, or TouchNet. Using these partners means you are less likely to experience technical issues. You are less exposed to liability concerns, and you will benefit from higher security standards.
