Cyberlands.io - API Penetration Testing

A cybersecurity architecture for a Mobile-first Digital Government - Part 1

A modern government organization produces a large number of IT solutions. Their prompt adoption and execution inevitably demand remote access to the organization's IT services. In practice, remote access turns into mobile access — after all, modern smartphones support any remote access technologies.


This way, information and secrets belonging to the state begin to flow in a polygon — the IT perimeter of the organization, home IT infrastructure, work laptop, and personal smartphone of an employee.


In such a complex configuration, it is no wonder even the first persons of the state get hacked — as it happened to Hillary Clinton (who was the Secretary of State — the head of the US Department of Foreign Affairs at that time). She used personal email to store official correspondence, more than 2 000 letters from which, after being discovered, received one or another classification.


Clinton can be understood — no manager can imagine themselves without convenient remote access to mail and calendar. Having a large number of specialized employees, business trips to regions and districts lead to the need to have access to information systems from anywhere in the country or even globally.

Every coin has two sides… and some have more than two

You need to decide on a strategy before shaping the rules of the game. The process of establishing the procedure for employees to handle mobile information, as well as developing a cybersecurity architecture, requires some thought.


As in the well-known tale, due to the specifics of the public administration sector, there are only three strategies: "open", "formal" and "complete". Let's put the protection of state secrets out of the way since the processing of state secrets requires secure premises, which means that it is conceptually poorly compatible with the mobility of IT services.


An "open" strategy implies a direct and unambiguous legal prohibition for employees of the organization to transfer any confidential information outside its perimeter. It is rather difficult to implement the ban at the technical level, but this is not the main point. The main thing is that the ban must be legally correct and communicated to all employees of the organization (with their signature, and ideally — as part of the regular control of cybersecurity operations).


With a high degree of probability, employees will technically still be able to access confidential information through remote channels. But if the organization ignores the instructions of the head management, it has much more significant problems than cybersecurity.


The "formal" strategy is focused exclusively on the requirements of regulators in the field of technical and cryptographic protection of confidential information. Practically in any government organization, there is already some groundwork in place regarding compliance with regulatory requirements for the protection of confidential information. All that remains is to scale existing practices to new transmission channels, places for processing and storing information.


Separately, I note that "confidential information" (in common parlance — CI) is a closed list of information: personal data, the secrecy of the investigation, and a number of other secrets protected by law. Completely different information can be confidential from a manager's point of view, and from a technical point of view, it is better to protect it without involving the whole bulk of regulatory requirements.


The "complete" strategy will be the choice of government organizations, for which, for one reason or another, cybersecurity is vital. For example, they can provide vital services to citizens, process significant amounts of financial data or the intellectual property of commercial enterprises, be connected to dozens of "third parties" (each of which may have its own security concerns).


Such organizations need to meet the requirements of regulators (historically aimed at ensuring the confidentiality of the information). In addition, they can benefit from an audit of the mix of IT services and access devices. This ensures the development of a holistic and complex cybersecurity architecture to protect the company's key assets.


Let's now take a closer look at each of the three approaches.

We have nothing to hide or "open" architecture

"Open" architecture (OA) aims to ensure the availability and reliability of the organization's information because mobility can be not only a data leak channel but also a point of entry into an organization's IT services. Let's say a laptop is lost by the press secretary of the department. Imagine it being used to send an "official" statement of the department with information discrediting the head to the business publications. A nightmare, isn't it?


In the past 3-5 years, a change of paradigm took place. The efforts were historically focused on quality management of the classic Deming cycle (Plan-Do-Check-Act, PDCA) in ensuring the cybersecurity of leading international corporations. Nowadays, the cyber threat-oriented cycle for protecting critical infrastructures from the USA National Institute of Standards and Technology has gained particular popularity. The NIST CSF (Identify - Protect - Detect - Respond - Recover) cycle reflects the full spectrum — five types of activities that are required to identify, prevent and respond to cyber threats.


OA consists of five blocks — audit, protection, monitoring, response, and recovery, accordingly. By the way, the practice of ensuring fire safety in the state is de facto similar - there is inspection (audit), and protection (compliance with requirements), and monitoring (based on awareness and signals from citizens), and response and recovery — fire brigades and assistance to fire victims.


The OA audit block is aimed at determining the current situation in all segments of the enterprise information system:

  1. Users — what they are required to do and what they know (standards, policies, training, and knowledge testing);

  2. Accounts — what are the password policies (password complexity, frequency of password changes, is there a lock after an incorrect entry);

  3. Channels of access to services — whether encryption of data transmission between service cores and access devices are provided;

  4. Access devices — are there unified security standards for access devices (PCs, laptops) — antiviruses, encryption of mobile access devices, the obligatory installation of corrections (patch management);

  5. Service core — whether security audits were performed when the services were brought to the Internet, and whether event logs were enabled to enable future investigations.


Let me emphasize that in fact, mobile IT services can commonly be located outside the perimeter of the organization (at some point, the media reported that a significant percentage of the contact addresses of public procurement tenders are located with external e-mail providers).


Within the framework of OA, it is reasonable to equate external services with internal ones, implementing OA in the part where it is possible and rational (for example, somewhere you can protect the data of key employees, and somewhere you can insist on using a corporate service).


The OA protection block is aimed at increasing cybersecurity in all five segments of the enterprise information system that will be "mobilized":

  1. "Users" segment — development and implementation of ToS for mobile users. Among the classic recommendations are not to use public Wi-Fi networks (without encryption), close the keyboard when entering a password, promptly report the loss of an access device with connected IT services of the organization, as well as the compromise of passwords or access tokens.

  2. "Accounts" segment — user accounts of mobile IT access services must be protected by strong password policies (for example, Group Policy, ActiveSync) and multi-factor authentication. Two-factor authentication must be compatible with the international protocols like OAuth2. In the absence of financial possibilities for the implementation of two-factor authentication, it is imperative to implement a compensating measure — an account lockout policy after a certain number of attempts. This policy has the side effect of causing service outages with a bogus attack. But given the ability to sort out passwords for accessing an organization 24 hours 365 days a year, there may be no other alternative. To reduce the risks associated with the loss of devices, I note the usefulness of the policy of requiring a password to be entered after a certain waiting period.

  3. "Access channels" segment — access channels must use encryption (S/MIME, VPN client, VPN tunnel MDM solutions). By the way, in order to avoid conflict with the regulatory requirements, encryption in the internal regulatory documents of the organization can be called coding.

  4. "Access devices" segment — devices for accessing IT services must be protected no worse than stationary PCs, at least a password for accessing the device must be set, built-in encryption of drives on iOS/OS X/Windows/Android platforms must be used, strong password policies (local accounts, PIN Security) must be in place

  5. "Service core" segment — the core of services should be built using technologies with long-term support by the manufacturer (no End of Support!). It is advisable to use the latest technologies (they usually have more built-in security technologies, for example, Windows 10 includes Credential Guard technology, which effectively counteracts the "scourge" of Windows infrastructures - the classic Pass-the-Hash attack).


Before launching services on the Internet, you need to audit their security — at least with free scanners like Microsoft MBSA, OpenVAS, and check critical services for compliance with the security requirements of manufacturers (all major vendors have the so-called Security Guides) and/or best practices (for example, classic CIS). To ensure the possibility of subsequent monitoring and investigation, it is necessary to configure the logging systems in the service cores. Planning and implementing data backup procedures will be a cross-cutting measure for all segments.


The OA monitoring block is aimed at understanding the current situation with the cybersecurity of mobile IT services. The problems can be identified through signals from users based on the results of a loss, according to the results of strange behavior of IT services (for example, a sudden account lockout due to a one-time incorrect password entry), through identifying brute force attempts (for example, using periodic scripts).


The OA response block is structured based on simple scenarios from the lifecycle of access devices:

  1. Loss of the device. You need to change passwords to services, block device access to services and make full remote wipe (if the device is corporate);

  2. Anomaly in IT — strange behavior of an IT service / brute-force hacking attempt. It is necessary to change passwords, identify the source of brute-force attack, temporarily change the antivirus on access devices (identify viruses that are invisible to the current antivirus), conduct further investigation. It is possible to tighten password policy or disable old unused service accounts (a common reason for unsuccessful domain logon attempts).


OA recovery block is aimed to instruct the user. Give him/her new credentials, provide a new corporate device, if possible. If necessary, restore data from backups. It is advisable to analyze the causes of the incident, to learn the lessons in order to develop and implement corrective measures.


OA implies the maximum possible use of built-in cybersecurity measures of popular platforms and mobile services (for example, the ability to remotely wipe Microsoft Exchange ActiveSync data). If the built-in measures are insufficient, separate protection measures can be purchased. If you do not have the financial ability to purchase commercial security tools (for example, solutions from multi-factor authentication providers), you can use Open Source (for example, Gluu). However, to use Open Source tools, you will have to pay for additional time for your employees training.


Depending on the degree of readiness and the size of the organization, the OA implementation project can be implemented in a few weeks or months, often without additional budgetary expenses.


In the second part of our high-level cybersecurity architecture for a Digital Government we'll review other two types of architectures - formal and complete. Stay tuned!:)
Cyberlands.io Team