FAQ
General
Q.
When to create a ticket?
A.
In general tickets need to be created in following scenarios.
1. New subscription provisioning - we need few application related information while provisioning the subscription
2. Ingress onboarding
3. Open IAM onboarding
4. Centralized AKS and its onboarding
5. Access to subscription/tenant/resource group.
6. Onboarding on MFT
7. Email account creations/provisioning
8. Any other technical issues related to Tier0 Services
Tickets needs to be created in cloud ops group - “OSGS Cloud Ops Support” group. Cloud ops team will reach out to Tier0 Eng team if needed. Only after creating the ticket, you can reach out to the concerned person directly(only in case of urgency).
Q.
What time it takes to resolve?
A.
Please refer to the SLA below.
| Capability | SLA |
|---|---|
| Tenant and subscription creation (including approvals) | 3-4 weeks |
| Tier0 Provisioning (Centralized Logging, Policies etc.) | 2-3 Weeks |
| CAKS onboarding (excluding application team’s testing and deployments) | 2 weeks |
| Ingress onboarding activities including Domain registration (excluding customer testing and vulnerability fixing) | 2-3 weeks |
| Procuring the license and execute the Email onboarding activities (excluding application team testing for sending emails) | 5-6 weeks |
| Any other technical issue | 2 weeks |
Q.
Are we supposed to send emails after creation of each ticket?
A.
Email is not required.
Q.
How Tier0 can close the ticket without owner(created By) accepting it.
A.
Upon providing the solution, tickets are first put in ‘pending closure’ state and as per SN standard procedure the ticket is closed after 5 days if no action is taken. Any ticket that is not related to Tier0 is marked ‘Cancelled’.
Q.
Why ticket creation is mandatory. It should only be required after the implementation of deployment has finished or for M&O related activities.
A.
Tier0 Engg./CloudOps team work with multiple engagements and development of applications as well. So to provide dedicated assistance, ticket creation seems to be efficient way in this situation.
Q.
Why the onboarding and setup timelines are long?
A.
We do not have dedicated M&O team, the same engineering team works on the onboarding activities as well, hence the extensive timeline.
Q.
What are the guideline on security patching?
A.
As of now application team will be responsible for patching of application resources and Tier0 will be responsible for patching Tier0 resources.
Q.
Is there any charge back on using Tier0 or any other application like OpenIAM, Jira, Graphana etc?
A.
At this point of time, there is no chargeback on using Tier0 (subject to change). The HCC chargebacks will be applicable as is. Also, HCC chargeback is being negotiated to <10% for next year onwards.
Q.
How is Tier0 going to handle non cloud native application developed technologies e.g. custom Java MicroServices and MuleSoft for logging?
A.
As long as micro-services are deployed in Azure e.g., in AKS, application logs can be sent to centralised logging.
Q.
How can I keep up to date/informed on Tier 0 progress and updates to the the roadmap?
A.
The upcoming features are available in the following link. Otherwise, you can also visit the AHA dashboard to have look at the progress and roadmap.
Q.
Once we establish the features for one environment, then can it be applicable to all the environments or each time we need to send a separate request.
A.
The setup is not for each environment, but rather for each client. e.g., for NC multi tenant subscription, once we provision the subscription, after that you can create as many as environment you need.
There is a prior step where if tenant is needed for that application. If separate tenant is needed, then we create the separate tenant.
Q.
What are the prerequisite to use Tier0 solution in terms of application being on the same or other cloud e.g. Google Anthos.
A.
The application has to be on Azure to provision to Tier0. Within Azure, It could be either in OCC cloud or SGS cloud. Although currently, it only supports Azure cloud, in future roadmap we do have plans to make Tier0 multicloud supported(AWS, Google etc.)
Centralized Logging
Q.
How to access logs in Azure?
A.
Customers can see logs in their subscription at RG level.
Q.
What type of logs application team should send to centralized logging e.g. events or incidents?
A.
Following is the list of events:
1. Server alerts and error messages
2. User log-on and log-off (successful or unsuccessful)
3. All system administration activities
4. Modification of privileges and access
5. Start up and shut down
6. Application modifications
7. Application alerts and error messages
8. Configuration changes
9. Account creation, modification, or deletion
10. File creation and deletion
11. Read access to sensitive information
12. Modification to sensitive information
13. Printing sensitive information
14. Anomalous (e.g., non-attributable) activity
15. Data as required for privacy monitoring privacy controls
16. Concurrent log on from different workstations
17. Override of access control mechanisms
18. Process creation
19. System access, including unsuccessful and successful login attempts, to information systems containing personally identifiable information (PII)
20. Successful and unsuccessful attempts to create, read, write, modify, and/or delete extracts containing PII from a database or data repository
21. Privileged activities or system level access to PII
22. Concurrent logons from different workstations, and
23. All program initiations, e.g., executable file.
Q.
Are there any technical documentation available for developers to configure their repos to integrate with the centralised framework?
A.
We are working with Microsoft for custom log ingestion. Most vendor apps follow an industry standard for logging so we can use default connectors and then map the log elements to the LAW data model. These are the mandatory steps for ingesting logs into a SIEM to set alerts on log events.
To get more technical assistance please raise a Service Now ticket where the developers can help with the same. Additionally please have a look at the Technical documentation
Q.
How is Centralised logging different than Splunk
A.
| Centralized Logging | Splunk |
|---|---|
| EIS Endorsed and MARS-E compliant. (Also, provides clients the ability to access their logs) | Compliance issue as per the customer contracts (e.g., one of the client requirement is to access their logs and they will never be able to do that in an optimum enterprise environment.) |
| Supports cloud native services | Splunk is not cloud native |
Q.
Monitoring logs also has a requirement to generate logs. How can we capture that part?
A.
Monitoring logs or diagnostic logs that are captured through log analytics are typically exposed through Azure monitor. In our future roadmap, the next step is to integrate JSM to expose the logs through it.
The monitoring decision such as what to monitor is the application team’s responsibility. Tier0 provides the framework and access to logs, whereas the decision to monitor the logs, and report generation is customisable by the customer.
Tier0 Alerts and Notifications
Q.
What kind of alerts are included in the solution? Are they application alerts?
A.
The Health alerts are actually security alert. Microsoft has predefined around 200 plus security measures and it monitors the log in the LAW from security incident perspective. And if it identifies any incident e.g., if somebody tries to log in more than three time then it will create an incident. So these are the Microsoft defined security measures that are in place. Alert is the outcome, of these security measures.
Q.
What kind of vulnerabilities are included in the email notification?
A.
There are primarily three types of vulnerability that are added in the e-mail. SQL, VM and container registry. These vulnerabilities are pulled from defender report that are from source or infrastructure level. These and are not application vulnerabilties.
OpenIAM
Q.
While doing the AAD integration, is it required to bring down the OpenIAM?
A.
No, there will be no downtime.
Q.
At what level the OpenIAM to AAD integration should happend, org level or OpenIAM level?
A.
Neither, it is at content provider level.