Global access list applies logically to the entire firewall in inbound direction to all interface.
If there are existing interface access lists, those will be considered first and instead of having implicit deny any any at the end of interface ALCs, the Global access list is processed and in case of non-matching rule, the implicit deny any any is used at the end of Global access list.
To create global access list using asdm open access rule, add access rule, and for interface choose -Any-
To create global access list using CLI:
#access-list GLOBAL extended permit tcp any any
#access-group GLOBAL global
ACL overrides initial traffic flow policies based on security level: 100- the most trusted and 0 – not trusted.
By default traffic from higher to lower sec level is allowed but not from lower to higher. For this type of traffic we need ACL.
Global access list are not replicated on each interface so they save memory space.
Use packet-trace to check the rule:
packet-tracer input VLAN49 tcp 150.1.1.1 20000 150.1.2.2 21
#show access-list
#show access-group
CCIE Security Blog 
Thanks for posting global access policy through command line
What is the difference in the use of access lists on the interface and global mode (with an explicit deny ip any any) on cisco ASA 9,x from the point of view of safety and resources?
Global ACL will be applied to ALL interfaces in inbound direction. It is easy way of applying a set of ACL to the firewall. On the other hand, firewall can fulfill more detailed control features using ACLs on individual interfaces. Each interface can have two ACL applied: on inbound and one outbound. So this will provide more robust and detailed security options but will provide a bit more burden on firewall resources. If you spec your firewall correctly for the job it will be doing, you will not have any issues with two ACLs per interface. Regardless of the way firewall presents the ACLs lists to the admin user (using objects, service groups, etc) firewall still has to break down the objects and do one line of ACL at the time.
From the security standpoint, more ALCs means more granular control but on the other hand, more admin work. I haven’t seen firewall struggling with performances when dealing with ACLs; i saw badly configured firewall struggling to keep up with DoS or DDoS attacks but not with ACLs.
By default firewall will deny any traffic that is not allowed; that being said explicit deny any any at the end of ACL will provide you with hit count entries in ACL (or in log collector) so you can get more info about traffic trying to go thru your firewall, source and destinations hosts. Again, no burden on firewall with this additional line.
Thanks for following.
HTH
Bellow explanation is related to ASA ver 8.2. There are some differences in ver 8.4 and up and also with FirePOWER service module, being a new kid in the block in terms of packet processing.
The interface that receives the packet is called the ingress interface and the interface through which the packet exits is called the egress interface. When you refer to the packet flow through any device, the task is easily simplified if you look at it in terms of these two interfaces.
So if we have inside network (192.168.10.0) and DMZ network (172.16.10.0) with web server (172.16.10.5) and an inside user (192.168.10.5) attempts to access a web server the packet flow looks like this:
Source address – 192.168.10.5
Source port – 22966
Destination address – 172.16.10.5
Destination port – 8080
Ingress interface – Inside
Egress interface – DMZ
Protocol used – TCP (Transmission Control Protocol)
Here are the individual steps in detail:
The packet is reached at the ingress interface.
Once the packet reaches the internal buffer of the interface, the input counter of the interface is incremented by one.
Cisco ASA first looks at its internal connection table details in order to verify if this is a current connection. If the packet flow matches a current connection, then the Access Control List (ACL) check is bypassed and the packet is moved forward.
If packet flow does not match a current connection, then the TCP state is verified. If it is a SYN packet or UDP (User Datagram Protocol) packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged.
The packet is processed as per the interface ACLs. It is verified in sequential order of the ACL entries and if it matches any of the ACL entries, it moves forward. Otherwise, the packet is dropped and the information is logged. The ACL hit count is incremented by one when the packet matches the ACL entry.
The packet is verified for the translation rules. If a packet passes through this check, then a connection entry is created for this flow and the packet moves forward. Otherwise, the packet is dropped and the information is logged.
The packet is subjected to an Inspection Check. This inspection verifies whether or not this specific packet flow is in compliance with the protocol. Cisco ASA has a built-in inspection engine that inspects each connection as per its pre-defined set of application-level functionality. If it passed the inspection, it is moved forward. Otherwise, the packet is dropped and the information is logged.
Additional security checks will be implemented if a Content Security (CSC) module is involved.
The IP header information is translated as per the Network Address Translation/ Port Address Translation (NAT/PAT) rule and checksums are updated accordingly. The packet is forwarded to Advanced Inspection and Prevention Security Services Module (AIP-SSM) for IPS related security checks when the AIP module is involved.
The packet is forwarded to the egress interface based on the translation rules. If no egress interface is specified in the translation rule, then the destination interface is decided based on the global route lookup.
On the egress interface, the interface route lookup is performed. Remember, the egress interface is determined by the translation rule that takes the priority.
Once a Layer 3 route has been found and the next hop identified, Layer 2 resolution is performed. The Layer 2 rewrite of the MAC header happens at this stage.
The packet is transmitted on the wire, and interface counters increment on the egress interface.
Here are some useful commands that help track the packet flow details at different stages in the process:
show interface
show conn
show access-list
show xlate
show service-policy inspect
show run static
show run nat
show run global
show nat
show route
show arp
Regards