3. DDoS 트랜드
• 인프라 레벨 공격 (Layer 3 / 4)
– 평균 공격 규모 900Mbps (50%는 500Mbps 이하)
– 전체 공격 중 약 78% (공격의 용이성)
• 어플리케이션 레벨 공격 (Layer 7)
– 나머지 22% 는 포트 80 & 443 에 대한 공격(보다 복잡함)
• 멀티 팩터 – 동시에 다른 형태의 공격 조합
• 증폭 공격(NTP, SSDP, DNS, Chargen, SNMP)
• Hit and run DDoS (91% < 1 시간), 연막 공격 비중(16-18%)
Source Arbor Networks
4. 전형적인 인프라 레벨의 공격 – Layer 3/4
• TCP SYN Flood
SYN
SYN
SYN
Connection Table
5. 반사/증폭 공격 – Layer 3/4
• UDP (DNS) Amplification Flood
192.0.2.1 198.51.100.4
src=198.51.100.4
dst=203.0.113.32
Reflectors
203.0.113.32 • NTP
• DNS
• SNMP
• SSDP
UDP Packet with
spoofed src IP
Large response packet
sent to victim
6. 전형적인 어플리케이션 레벨의 공격 - Layer 7
Web ServerAttacker(s)
GET
HTTP GET Flood
Slowloris
GET GET GET GET GET
G - E - T
• POST Flooding
그외, cache-busting attack, WordPress XML-RPC flood 등
7. OSI 모델 계층별 대표 공격유형
# 계층 유닛 설명 대표적인 공격 벡터
7 응용(Application) 데이터
어플리케이션에 대한 네트웍
프로세스
HTTP floods, DNS query
floods
6 표현(Presentation) 데이터 데이터 표현과 암호화 SSL abuse
5 세션(Session) 데이터 호스트 간 통신 N/A
4 전송(Transport) 세그먼트 종단 간 연결 및 신뢰성 SYN floods
3 네트웍(Network) 패킷 경로 결정과 논리적인 어드레싱 UDP reflection attacks
2 데이터 링크(Data Link) 프레임 물리적인 어드레싱 N/A
1 물리(Physical) 비트 미디어, 시그널,바이너리 전송 N/A
각 계층에서 발생하는 공격의 유형이 상이하고 대응 방식도 완전히 다르기
때문에, 이와 같은 구분을 이해하는 것이 굉장히 중요
8. 6가지 효과적인 대응 방안
AWS 서비스들을 앞단에 배치하세요.
공격지점을 최소화 시키세요.
노출된 리소스에 대한 대책을 세우세요.
공격을 흡수할 수 있는 확장성을 구현하세요.
정상 상태에 대한 기준을 확립하세요.
공격에 대응하기 위한 계획을 수립하세요.
1
2
3
4
5
6
9. 1. AWS 서비스들을 앞단에 배치하세요.
• 레이어 3/4 공격을 방어하기 위해 Amazon API Gateway 나 Amazon
CloudFront와 같은 AWS서비스들을 어플리케이션 앞단에 배치
캐슁기능을 통해 성능 및 보안성 향상
• 최근 서울 리전에 출시된 Amazon API Gateway가 제공하는 기능:
• User authentication.
• Request throttling.
• Response caching.
• Requests logging.
10. 여러분의 VPC가 Layer 7 트래픽만 받도록 구성
CloudFront
DDoS
HTTP
SYN /
UDP
HTTP Customer
Solution
11. Amazon API Gateway의 요청 플로우
인터넷
모바일 앱
웹싸이트
서비스
API
Gateway
AWS Lambda
functions
AWS
API Gateway cache
EC2 / Elastic
Beanstalk
엔드 포인트
기타 접근가능한
퍼블릭엔트포인트
Amazon CloudWatch
모니터링
1.REST 요청
3.캐쉬 체크
4.요청 전달(Throttling)
5.실행 결과
6.로깅
7.결과 전송
2.인증
12. AWS 플랫폼의 보안기능을 이용하여 워크로드
줄이기
웹
방화벽
웹
어플리케
이션
데이터
캐쉬
싸고 확장성 있는 비싸고 손상되기 쉬운
HTTP
캐쉬
AWS
API
손상되기 쉬운 백엔드 컴포넌트 보호
13. 2. 공격지점을 최소화 시키세요.
공격 지점을 최소화할 수
있는 아키텍쳐
• 인터넷 연결지점 최소화
VPC를 이용하여 공격지점
최소화
• VPC와 Internet Gateway 구성
14. AWS 방화벽 – 보안그룹 ( Security Group )
보안그룹 규칙
적용포인트 : 인바운드/아웃 바운
Protocol : 모든 인터넷 프로토콜
지원
IP/Port 에 대한 접속 허용/차단
Stateful 방화벽
보안그룹
15. AWS 기본 보안 서비스 - Network ACL(NACL)
Availability Zone
‘A’
Availability Zone
‘B’
Subnet ACL
예시
16. VPC 서브넷, 보안그룹, NACL
웹/어플
리케이
션 서버
DMZ 퍼블릭 서브넷
ssh
bastion
NAT
ELB사용자
관리자
인터넷
Amazon EC2
보안그룹
보안그룹
보안그룹
security group
frontend 프라이빗 서브넷
TCP: 8080
Amazon EC2
TCP: 80/443
backend 프라이빗 스브넷
security group
TCP: 1433;
3306
MySQL db
TCP: Outbound
TCP: 22
17. 3. 노출된 리소스에 대한 대책을 세우세요.
• CloudFront / S3 리소스에 대한 제한된 접근
• Origin Access Identity(S3)
• Route 53을 통해 DNS 노출 정보 최소화
• Create hosted zone: www.example.com
• Create A record set
• Create alias to CNAME
• Point alias to CloudFront URL
• Point CloudFront origin to ELB
• 3rd party WAF를 통해 어플리케이션 보호
• Request rate limits
• 특정 유형의 요청 블락
18. 비싼 리소스에 대한 보호조치 – WAF(웹 방화벽)
• 확장이 쉽지 않은 백엔드 리소스에 대한 보호
• WAF : 어플리케이션 레이어의 트래픽들을 조사하고 필터링 – HTTP
& HTTPS
• OWASP Top 10
• Rate Limiting
• Whitelist / Blacklist (Customizable Rules)
• Native Auto Scaling with WAF Sandwich
• Learning Engine
• Benefits
• ACLs 을 보완해줌(누가 공격하고 있는지 정확히 파악할 필요성 경감)
• 적법한 사용자에게 가용성 제공
https://www.owasp.org/images/2/2c/OWASP_Top_10_-_2013_Final_-_Korean.pdf
20. 4. 공격을 흡수할 수 있는 확장성을 구현하세요.
AWS 를 통한 수직적 / 수평적 확장성 구현
공격을 넓은 지역으로 소산시켜줌
공격자가 공격규모를 늘리는데 많은 리소스가 필요하게
해줌
DDoS공격을 분석하고 대응하기 위한 시간을 벌어줌
덤으로 장애 시나리오에 대비한 아키텍쳐
21. AWS 환경을 통한 수직적 / 수평적 확장
EC2 Enhanced
Networking
활성화
Elastic Load Balancing
& Auto Scaling 설정
Amazon CloudFront를
통해 지역별로 분산
Amazon Route 53의
Shuffle Sharding,
Anycast Routing을
통한 가용성 향상
• 공격자가 더많은 노력을 쏟아야…
• 인스턴스, 네트웍에 대한 유연성
• 생각하고 대응할 시간을 제공
22. 5. 정상 상태에 대한 기준을 확립하세요.
• CloudWatch를 통해 정상 사용 수준에 대한 이해와 측정
• 비정상 수준 또는 공격 패턴을 판별하는 명확한 기준으로 활용
• 공격 과정에 대한 모니터링 및 기록
• 오토스케일링 정책의 조건으로서 CloudWatch 알람 이용
23. CloudWatch 모니터링 권장 메트릭
Topic Metric Description
Auto Scaling GroupMaxSize The maximum size of the Auto Scaling group.
AWS Billing EstimatedCharges The estimated charges for your AWS usage.
Amazon CloudFront Requests The number of requests for all HTTP/S requests.
Amazon CloudFront
TotalErrorRate The percentage of all requests for which the HTTP status code is 4xx or
5xx.
Amazon EC2 CPUUtilization The percentage of allocated EC2 compute units that are currently in use.
Amazon EC2 NetworkIn The number of bytes received on all network interfaces by the instance.
Amazon EC2
StatusCheckFailed A combination of of StatusCheckFailed_Instance and
StatusCheckFailed_System that reports if either of the status checks has
failed.
ELB
RequestCount The number of completed requests that were received and routed to
registered instances.
ELB
Latency The time elapsed, in seconds, after the request leaves the load balancer
until a response is received.
ELB
HTTPCode_ELB_4xx HTTPCode_ELB_5xx The number of HTTP 4XX or 5XX error codes generated by the load
balancer.
ELB BackendConnectionErrors The number of connections that were not successfully.
ELB SpilloverCount The number of requests that were rejected because the queue was full.
Amazon Route 53 HealthCheckStatus The status of the health check endpoint.
24. 6. 공격에 대응하기 위한 계획을 수립하세요.
공격을 대비하여 다음을 확인:
• 복원력있는 아키텍쳐인지 수립한
아키텍쳐에 대한 검증 및 사전 기능 테스트
(AWS에 사전 공지 필수!!)
• 공격 수용시 서비스 확장의 규모 및 비용에
대한 부분 고려
• 공격 받을 경우 비상 연락망
25. AWS 지원 요청
Account Team
• AWS 담당 영업은 여러분들의 대리인
• Solutions Architect의 축적된 경험 활용
AWS 써포트 티어
• 비지니스 – 전화/채팅/이메일, 1 시간 응답
• 엔터프라이즈 – 15 분내 응답, 전담 Technical
Account Manager, proactive notification
28. 권장 아키텍쳐 – 인바운드 제어
Inbound HTTP
CloudFront
Amazon S3
WAF
샌드위
치
Dynamic
App
App
AppPeering
DDoS
사용자
VPC peering기능을 이용하여 다수의 어플리케이션을 지원할 수 있는 확장성 있는
아키텍쳐
29. 권장 아키텍쳐 – 인바운드 제어
WAF
샌드위
치
Private
Public
Peering
connection
App
App
Proxy
Cloudwatch로
로그 전송
구성정보
정상적인 요청 전달
CloudFront
빠르게 확장 가능한 인바운드 보안 게이트 웨이
30. 권장 아키텍쳐 - 오픈 소스를 활용한 구성
WAF
샌드위
치
Private
Public
CloudFront
WAF stack
빠르게 확장 가능한 NGINX reverse-proxy
위협 패턴 기반 다이내믹한 규칙 업데이트 -
LUA firewall
OWASP Top 10 기반 기본 규칙
- Cloudwatch Logs captures blocks
- Cloudwatch Alarms : 403 에러 탐지 /
대응
31. 권장 아키텍쳐 – 아웃 바운드 제어
Outbound
Proxy
AWS API
Endpoints
Inbound
WAF
Web
Application
Outbound HTTP
Inbound HTTP Inbound
API requests
CloudFront
아웃바운드 트래픽을 다른 경로로 전송
32. 권장 아키텍쳐 – 아웃 바운드 제어
모든 HTTP 및 API 접근에 대한 아웃 바운드 트래픽을 프록시를 통하도록 구성 –
중요 데이터 유출 검사
Squid
Proxy
Private subnet
Public subnet
Peering
connection
AWS API
Endpoints
WAF
App
App
• S3로부터 구성정보
Bootstrap
https://blogs.aws.amazon.com/security/post/T
xFRX7UFUIT2GD/How-to-Add-DNS-Filtering-to-
Your-NAT-Instance-with-Squid
34. 얼마나 빨리 대응할 수 있는가에 대한 문제
• DDoS 보안은 빅데이터
• 공격의 징후를 정확히 판정하기 위해 로그를 남기고 취합.
• 어떻게 AWS서비스들을 활용하여 도움을 받을 수 있을지.
• 지능적이고 즉각적인 대응
• Cloudwatch alarm 기능을 활용하여 WAF 규칙을 자동으로 업데이트
하는 워크플로를 구성 – AWS lambda를 이용하여 의심되는 Source IP를
WAF Rule 조건에 포함
• 실시간 WAF 규칙 업데이트 – 예: 특정 IP로부터 5분간 5번이상 공격을
받은 경우, 그 IP로부터의 접근을 30분동안 막음.
35. 요약
Amazon Virtual Private Cloud
• Network Access Control Lists
설정(ACLs)
• Private / Public Subnets & DNS
구성
• VPC Flow Log 설정
Amazon CloudWatch
• 모니터링 / 경보
Elastic Load Balancing
• 부하분산
• 오토 스케일링
Amazon CloudFront
• Scale, capacity, absorb
• Geo Restriction
Amazon APIGateway
• Authentication / Throttling
Amazon Route 53
• Shuffle sharding, Anycast
AWS Marketplace
• WAF 샌드위치
• Proxies
DDoS 대응 계획 수립
38. [UTM] Agent (Hosted) 타입
VPC 10.0.0.0/16
Public Subnets
Private Subnets
10.0.1.0/24
10.0.128.0/24 10.0.129.0/24
…
Firewall
IDS/IPS
AV/Malwar
e...
UTM
Manager
WAS
… Batch
…
10.0.0.0/16 : Local
0.0.0.0/0 : NAT
…
10.0.0.0/16 : Local
0.0.0.0/0 : IGW
…
A A
10.0.2.0/24
WEB
…
A
10.0.127.0/24
NAT
A
대상 인스턴스에 agent 설치 후
이를 관리
Scalability , Availability 장점
AWS Security Group, NACL과 UTM
F/W기능을 조합하여 관리하여야 함
39. [UTM] Gateway 타입
VPC 10.0.0.0/16
Public Subnets
Private Subnets
10.0.1.0/24
10.0.128.0/24 10.0.129.0/24
…
Firewall
IDS/IPS
...
UTM
WEB
WAS …
DB
…
(10.0.0.0/16 : Local)
…
0.0.0.0/0 : UTM
10.0.0.0/16 : Local
0.0.0.0/0 : IGW
…
대상 subnet 내 트래픽이 UTM
인스턴스를 경유하도록 Route Table
설정
Network Security관련된 설정을
단일 UTM솔루션에서 관리
성능 병목점이나 Single Failure
Point 여부 확인 필요
AWS VPC 제공 기능(pub/pri subnet,
nat, nacl, …) 활용이 제한적임
40. [UTM] Gateway 타입 : Active – Standby
VPC 10.0.0.0/16
Public Subnets
Private Subnets
10.0.1.0/24
10.0.128.0/24 10.0.129.0/24
…
UTM
(Active)
WEB
WAS …
DB
…
(10.0.0.0/16 : Local)
…
0.0.0.0/0 : UTM
10.0.0.0/16 : Local
0.0.0.0/0 : IGW
…
UTM
(Stand
-by)
Conf. Sync.
Move EIP or
ENI
A-S형태로 구성 후 장애 발생 시
EIP나 ENI 를 Standby 인스턴스로
맵핑
A-S 가 단일 subnet을 벗어나 az간
구성이 가능한지, A-S 절체 시간이
얼마나 소요되는지 확인 필요
41. [UTM] Gateway 타입 : Active – Active
VPC 10.0.0.0/16
Public Subnets
Private Subnets
10.0.1.0/24
10.0.128.0/24 10.0.129.0/24
UTM
(Standalone)
WEB
WAS … …
(10.0.0.0/16 : Local)
…
0.0.0.0/0 : Firewall
10.0.0.0/16 : Local
0.0.0.0/0 : IGW
…
WEB
WAS
10.0.2.0/24
UTM
(Standalone)
AZ 1 AZ 2
StandAlone 타입으로 az간 구성 후
ELB나 Route53으로 이중화 구성
관리대상 서버의 subnet이
참조하는 route table 셋팅을
UTM으로 해야함
or
42. [UTM] 기존 UTM appliance 활용
YOUR AWS ENVIRONMENT
AWS
Direct
Connect
YOUR
PREMISES
Digital
Websites
Big Data
Analytics
Dev and
Test
Enterprise
Apps
AWS
Internet
VPN
44. AZ 2AZ 1
[WAF] Proxy형 WAF1
• 고객 VPC 내 proxy형 WAF 설치 운영
• ELB 샌드위치 내 WAF 구성 (상단
external ELB는 Route53으로 필요시
대체하거나 UTM 복합 구성)
• WAF 리소스를 모니터링하여 Scaling
구성 대비 필요
VPC 10.0.0.0/16
Public Subnets
Private Subnets
10.0.1.0/24
10.0.128.0/24 10.0.129.0/24
WAF
(Standalone)
WEB
WAS … …
WEB
WAS
10.0.2.0/24
WAF
(Standalone)
or
45. [WAF] Proxy형 WAF2
• Proxy형 WAF1의 변형으로 WAF 내
target 설정이 단일 IP 만 지원하는
솔루션
• WEB 서버를 WAF 타겟으로 하고
WEB/WAS 구간을 WAS bridge로
구성(internal ELB 구성도 OK)
• WAF 상단 구성은 ELB, Route53 또는
WEB 서버, UTM 선택 구성 가능AZ 2AZ 1
VPC 10.0.0.0/16
Public Subnets
Private Subnets
10.0.1.0/24
WAF
(Standalone)
WEB
… …WEB
10.0.2.0/24
WAF
(Standalone)
WAS
… …WAS
or
46. [WAF] AWS WAF (WAF on CDN)
WEB
WAS
WEB
WAS
www.example
.com
WAF on
CloudFront edges
users
Safe
Traffic
Edge
Location
Edge
Location
…
61 edges
WAF
WAF
hackers
Bad bots
legitimate
traffic
SQL
Injection,
XSS, ..
site
scripting
• CloudFront edge단에서
WAF가 monitor & filter처리
• 분산된 edge에서 처리되어
scaling에 대한 부담 없음
• SQL injection, XSS 룰셋 기본
제공
• CloudFront 사용이 전제됨
48. Why use a WAF?
• WAF 사용 목적
• Protect from SQL Injection (SQLi) and Cross Site Scripting (XSS)
• Prevention of Web Site Scraping, Crawlers, and BOTs
• Mitigate DDoS (HTTP/HTTPS floods)
• 특정 compliance 준수를 위해 WAF 를 구매하는 비율이 25-30%
수준
49. AWS AWF의 장점
실용적인 보안을
손쉽게 구성
유연한 룰셋 구성 DevOps 시스템과
통합이 용이
그리고 AWS의 장점인 ‘pay as you go’ 가격 정책
51. AWS WAF
• Amazon CloudFront 사용을 전제
• Edge 단에서 동작
• Self-service, easy deployment, pay
as you go
• 트래픽에 따른 자동적인 확장성
제공
• DevOps friendly
• “Do it yourself”
AWS WAF 와 상용 WAF 비교
Marketplace WAFs
• EC2에서 동작
• Managed service, licensing (BYOL),
and hourly based
• 확장을 위해선 추가적인 작업 또는
설정 필요
• 기능과 룰셋이 풍부하고 학습기능
52. [WAF] AWS WAF
WEB
WAS
WEB
WAS
www.a.com WAF on
CloudFront edges
users
Safe
Traffic
Edge
Location
Edge
Location
…
56 edges
WAF
WAF
hackers
Bad bots
legitimate
traffic
SQL
Injection,
XSS, ..
site
scripting
• CloudFront edge단에서
WAF가 monitor & filter처리
• 분산된 edge에서 처리되어
scaling에 대한 부담 없음
• SQL injection, XSS 룰셋 기본
제공
• CloudFront 사용이 전제됨
53. 네트워크 보안 제품 마켓플레이스 현황
Solution Company Product name Seoul Region Type
UTM Sophos Sophos UTM 9 (Support for Auto Scaling BYOL) OK Gateway
UTM Trend Micro Trend Micro Deep Security (Classic) OK Agent
UTM paloalto VM Series Next-Gen F/W OK Gateway
UTM Fortinet FortiGate-VM Limited (above c4) Gateway
UTM Check Point Check Point vSEC (PAYG) OK Gateway
UTM Barracuda Barracuda NextGen Firewall F-Series Limited (above c4) Gateway
WAF Fortinet FortiWeb-VM OK Gateway
WAF Penta Security CloudBric OK SaaS
WAF Penta Security Wapples OK Gateway
WAF Monitorapp Monitorapp OK Gateway
WAF Barracuda Barracuda WAF OK Gateway
WAF/DDoS Imperva Incapsular OK(from Tokyo) SaaS
WAF Imperva SecureSphere WAF AV1000 Gateway v11.0 None Gateway
2016.09.24 기준
55. AWS Partner hands-on labs 주제
• 등록 : https://aws.amazon.com/ko/events/hols/seoul-03/
Date Partner Session Title
10/10 Megazone 나만의 가상 데이터센터 만들기 (등록 마감)
10/17 Bespin Global 스크립트로 AWS 서비스 자동화 하기
10/24 Megazone 나만의 가상 데이터센터 만들기
10/31 GS Neotek AWS의 VPC 환경 구성하기
11/7 Saltware AWS의 Storage 및 CDN 서비스 활용하기
11/14 GS Neotek CloudFormation 템플릿을 활용한 VPC 환경 구성하기
11/21 Saltware AWS Lambda를 활용한 서버리스 디자인
Editor's Notes
TCP “3 Way handshaking” 과정에서 2단계 까지만.. 3단계 ack가 올때까지 약 75초 동안 대기. Backlog queue에 계속 쌓임.
1단계. A 클라이언트는 B 서버에 접속을 요청하는 SYN 패킷을 보낸다.2단계. B 서버는 요청을 받고 A 클라이언트에게 요청을 수락한다는 SYN 패킷과 ACK 패킷을 발송한다. 3단계. A 클라이언트는 B 서버에게 ACK 를 보내고 이후로부터 연결이 이루어지고 본격적으로 데이터가 교환된다.
해당 port만 영향. 잘 모르는 경우가 많음. netstat -na|grep SYN_RECV가 많으면 공격
Looks real.
Identify a very expensive resource
Flood, exhaust the available connections.
Complex.
Slow Lo
They are hard to detect as they look like valid connections from a slow user.
Keep the connection open
Looks real.
Identify a very expensive resource
Flood, exhaust the available connections.
Complex.
Slow Lo
They are hard to detect as they look like valid connections from a slow user.
Keep the connection open
The first thing we want to look at is the standard flow of an API call, including all components in the system
First, a request comes in from a client, this could be a mobile device, a web application or a backend service
The requests arrives at one of our CloudFront PoP locations, it’s accepted and routed through to the API Gateway in the customer’s region
The API Gateway receives the request, then checks for records in the dedicated cache (if it is configured). If there are no cached records available then it will forward the request to the backend for processing
The backend can be a Lambda function, a web service running on Amazon EC2, or any other publicly accessible web service
Once the backend has processed the request the API call metrics are logged in Amazon CloudWatch and the content is returned to the client
Here is a simple, single-layer web application spanning two availability zones in a single region. This one supports auto-scaling. We’ll use this model to discuss how we might achieve our objective of passively monitoring network traffic to and from the web servers.
Hide your origin URL/IP address. Make attackers attack AWS and not you.
Create hosted zone: www.example.com
Create A record set
Create alias to CNAME
Point alias to CloudFront URL
Point CloudFront origin to ELB
Shuffle Sharding
샤딩은 수평적인 데이터의 파티션들이 여러 대의 데이터베이스 서버로 분산되어 처리됨으로써 이중화 기능을 제공하는 것을 뜻합니다.
이와 유사하게 Amazon Route 53은 셔플 샤딩을 활용해 여러 곳의 PoP 으로 DNS 요청을 나누어 보냄으로써 여러분의 어플리케이션까지 도달하는 복수의 경로를 제공해 줍니다.
Anycast Routing
애니캐스트 라우팅 (Anycast Routing)은 여러 곳의PoP에서 같은IP주소를 사용함으로써 서비스의 가용성을 높여줍니다.
만약 DDoS 공격이 어느 하나의 PoP을 공격하여 무력화 시킬지라도, 셔플 샤딩을 통해 해당 장애가 한 곳으로만 국한되며 나머지 경로들을 통해 여러분의 인프라까지 이상없이 서비스 할 수 있습니다.
At AWS we have a number of levels of ways for you to get help. It’s best to start with your account manager, who can act as your advocate. We also have Solutions Archtiects who are your chief technical points of contact. They’re very knowledgeable and are a fantastic resource for you to bounce ideas off, and get technical feedback on what you’re trying to do.
WE have several tiers of support within AWS, but if you’re running sensitive workloads in AWS then we would strongly recommend buying either Business level or Enterprise level support. Business level support provdes phone, chat and email support, with a 1 hour response time. With enterprise support you get a quicker response time, but you also get a dedicated Technical Account Manager, who can also act as an additional advocate for you at AWS. Not only that, but if there is a problem, and you have Enterprise support, then your Technical Account Manger will reach out to you to let you know about it and what you should do about it.
RICH
RICH
AWS WAF gives customers the web security features they need, but with an approach to security that’s unique in three ways:
First…
TOM
TOM
….more to come later when we talk about a specific partner integration