Information Security Asked by user855 on January 25, 2021
Take for example – AWS STS token or JWT tokens.
Let’s say node A got a token for accessing a resource of account X on behalf of account X. Access includes read/write privileges.
Let’s say few minutes later the node A got compromised.
Nothing else knows that A got compromised.
Question Account X is also compromised now. Correct?
Question We will continue to provide renewed tokens to access account X to node A because we have not detected that node A is compromised yet. Correct?
Question What should we do to detect that node A is compromised?
There's not really enough information to determine the specifics here, but there are some general answers that can be provided.
In your scenario, the assumption by default should be that node A has had the ability to access and modify account X within the scope of the permission of its token. This is, generally, why tokens are usually limited to certain scopes, so that, for example, if node A needs to access directory information about account X, it cannot abuse that to also modify other information on the account.
This is also why automated tokens tend to be time limited—so that the abuse of account X by node A is limited to the life of its tokens—and why credential issuance is usually logged—so that any misuse can be easily determined and the extent of access can be readily discovered. If tokens are issued using sufficient entropy, it is also common to log their access using a hashed version of the token so that actions taken by a bad actor can be determined.
Whether, in this situation, it means that account X is compromised (that is, under the control of the attacker) depends on what data the attacker had the ability to access or modify, both due to the scopes and duration of the token and the design of the system. If, for example, the token grants the attacker the ability to do only cosmetic changes, like change personal names or avatars, then the account is, while potentially defaced, probably not compromised.
If your system permits the issuance of additional tokens to node A, then you may well provide it additional tokens. That, of course, depends on the design of the system.
To detect compromises, you will generally want to have some sort of automated measurements or metrics that detect indicators of compromise. What those are depend on the system. For example, if you know that nodes are generally only supposed to handle about 20,000 accounts per day, you may set up a dashboard or an alert to detect large numbers of issued tokens or tokens issued for many accounts, so you notice it's acting strangely. You may also monitor other indications of compromise, such as loading of additional kernel modules, unusual usage of
sudo, or access from or connections to unexpected systems. All of this depends on what you know about your instances and systems and requires that you build in suitable metrics and monitoring that are appropriate for your scenario based on suitable threat modeling. You will need to balance good detection and prevention of threats with gracefully handling the occasional anomalous but harmless traffic pattern and avoiding major inconvenience for staff.
Correct answer by bk2204 on January 25, 2021
2 Asked on December 10, 2021 by geo-m
0 Asked on December 10, 2021
3 Asked on December 8, 2021 by user136026
3 Asked on December 8, 2021 by ddbe
1 Asked on December 8, 2021 by dipesh-sunrait
1 Asked on December 6, 2021
2 Asked on December 4, 2021 by loopofnegligence
1 Asked on December 4, 2021
5 Asked on December 2, 2021 by askford
6 Asked on December 2, 2021
3 Asked on November 30, 2021 by iancool
3 Asked on November 30, 2021 by brad-stevanus
1 Asked on November 30, 2021 by houtanf
1 Asked on November 28, 2021
10 Asked on November 25, 2021 by lil-bits
1 Asked on November 25, 2021
2 Asked on November 25, 2021
1 Asked on November 23, 2021 by user109889
2 Asked on November 23, 2021
0 Asked on November 23, 2021 by gilad-naaman
Get help from others!
© 2023 AnswerBun.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP